API Rate Limiting Security Calculator
Model a token-bucket rate limit against a distributed attacker and check whether it still protects the backend.
Inputs
Attacker Sustainable Throughput
2,000.0req/s
Backend Saturation
40%
Requests Allowed per Key in the Window
650
Headroom Over Legitimate Peak
2.50×
Bypass Risk
5.50/ 9
Assessment
The backend stays protected at the modelled attacker scale
Step by step
Values used
Sustained limit, i.e. token refill rate = 10 req/s; Bucket capacity = 50 tokens; What the limit is keyed on = IP address — 7; Keys or addresses the attacker controls = 200 identities; Attack window = 60 seconds; Legitimate peak rate for one key = 4 req/s; Backend capacity = 5,000 req/s; Response to a breach = 429 with Retry-After — 4
API Rate Limiting Security
A token bucket allows burst + refill rate × window requests per key over a window; a distributed attacker holding k keys sustains k × refill rate requests per second.
Protection check
backend saturation = attacker throughput ÷ backend capacity × 100; headroom = refill rate ÷ legitimate peak rate.
Attacker Sustainable Throughput
= 2,000.0 req/s
Backend Saturation
= 40
Requests Allowed per Key in the Window
= 650
Headroom Over Legitimate Peak
= 2.50 ×
Bypass Risk
= 5.50 / 9
Assessment
= The backend stays protected at the modelled attacker scale
How it works
A token bucket permits a burst up to the bucket size and then settles to the refill rate, so the requests one key can make in a window is the capacity plus the refill over that window. The protective question is what happens when the attacker holds many keys: throughput multiplies by the key count while your backend capacity does not move. Per-IP limits are the default and the easiest to defeat — a few hundred residential proxies turn a 10 req/s limit into thousands, so the limit has to be sized against the backend rather than against one client.
Formulas
API Rate Limiting Security
A token bucket allows burst + refill rate × window requests per key over a window; a distributed attacker holding k keys sustains k × refill rate requests per second.
- burst
- Bucket capacity in tokens
- refill rate
- Sustained requests per second per key
- k
- Keys or addresses the attacker controls
Protection check
backend saturation = attacker throughput ÷ backend capacity × 100; headroom = refill rate ÷ legitimate peak rate.
- backend capacity
- Requests per second the origin can serve
- headroom
- How much slack a normal client has
Frequently Asked Questions
How is API Rate Limiting Security calculated?
A token bucket allows burst + refill rate × window requests per key over a window; a distributed attacker holding k keys sustains k × refill rate requests per second. A token bucket permits a burst up to the bucket size and then settles to the refill rate, so the requests one key can make in a window is the capacity plus the refill over that window. The protective question is what happens when the attacker holds many keys: throughput multiplies by the key count while your backend capacity does not move.
Why does API Rate Limiting Security matter?
Per-IP limits are the default and the easiest to defeat — a few hundred residential proxies turn a 10 req/s limit into thousands, so the limit has to be sized against the backend rather than against one client.
What values do I need to enter?
This calculator takes 8 inputs: Sustained limit, i.e. token refill rate, Bucket capacity, What the limit is keyed on, Keys or addresses the attacker controls, Attack window, Legitimate peak rate for one key, Backend capacity, Response to a breach. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
Should I rate-limit per IP or per account?
Per account or per API key wherever a caller is authenticated, because that is the identity the attacker cannot mint for free. Keep an IP limit as a coarse outer layer for unauthenticated endpoints, and add a global concurrency cap so the backend is protected even when the per-key maths is defeated.