As a best effort to find the "right" rate limits, I tend to combine historical norms (in case of migration projects) + some buffer, or based on business req (e.g. need to support X concurrent users, which translates to X req/s) + some buffer.
It would make the endpoints easier for DOS attacks that aren't caught by WAF (eg. low and slow attacks). But, at least you limit the blast radius to just one endpoint/API, as opposed to ALL the APIs in the region.
Also, if you have more critical endpoints then you can allow a bigger buffer to better handle unexpected spikes in traffic. You should also be more strict about the rate limits for low-priority endpoints.
The alternative is that your critical endpoints that are important to the user experience (which should be protected by some authenticated & authorization mechanism) can be taken offline by an attacker that DDOS a low priority and public endpoint (e.g. the "about us" page).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thank you :-)
As a best effort to find the "right" rate limits, I tend to combine historical norms (in case of migration projects) + some buffer, or based on business req (e.g. need to support X concurrent users, which translates to X req/s) + some buffer.
It would make the endpoints easier for DOS attacks that aren't caught by WAF (eg. low and slow attacks). But, at least you limit the blast radius to just one endpoint/API, as opposed to ALL the APIs in the region.
Also, if you have more critical endpoints then you can allow a bigger buffer to better handle unexpected spikes in traffic. You should also be more strict about the rate limits for low-priority endpoints.
The alternative is that your critical endpoints that are important to the user experience (which should be protected by some authenticated & authorization mechanism) can be taken offline by an attacker that DDOS a low priority and public endpoint (e.g. the "about us" page).