how should spike arrest rates be defined when I am designing an API Proxy that actually integrates with other external systems ? like what are the guidelines or best practices for the values that I will set ?
Solved! Go to Solution.
Hi @dareenhamdy,
When setting up SpikeArrest for an Apigee proxy, there are a few important things to keep in mind to get it right:
1. Choosing the right identifier.
If it's a system-to-system integration, I recommend using the client_id to track and apply rate limits based on the system making the request. This way, each system is treated uniquely.
If your API is accessed from a browser, it’s better to use a unique user identifier like an identifier obtained from session. This lets you manage traffic at the user level.
2. Set limits based on the consumer.
System accounts will likely need higher limits, like 100 requests per second, to handle the larger traffic.
On the other hand, for individual users, you can set a lower limit, like 5 requests per second, to prevent any one user from overwhelming the API.
3. Make sure variables are properly set.
It’s really important to check that the variables used for identifying clients and setting limits are always properly defined during runtime. If these are undefined, it can cause the API to lose protection, making it easier for an attacker to overload the system.
Here are a couple of rules that might help:
By following these steps, you can keep your API safe from traffic spikes and DoS attacks. Let me know if you need any more details!
Hi @dareenhamdy,
When setting up SpikeArrest for an Apigee proxy, there are a few important things to keep in mind to get it right:
1. Choosing the right identifier.
If it's a system-to-system integration, I recommend using the client_id to track and apply rate limits based on the system making the request. This way, each system is treated uniquely.
If your API is accessed from a browser, it’s better to use a unique user identifier like an identifier obtained from session. This lets you manage traffic at the user level.
2. Set limits based on the consumer.
System accounts will likely need higher limits, like 100 requests per second, to handle the larger traffic.
On the other hand, for individual users, you can set a lower limit, like 5 requests per second, to prevent any one user from overwhelming the API.
3. Make sure variables are properly set.
It’s really important to check that the variables used for identifying clients and setting limits are always properly defined during runtime. If these are undefined, it can cause the API to lose protection, making it easier for an attacker to overload the system.
Here are a couple of rules that might help:
By following these steps, you can keep your API safe from traffic spikes and DoS attacks. Let me know if you need any more details!