Skip to content
sec/atlas
back to the map
technique
stage: agir
2 min read

Adaptive rate limiting

A fixed per-IP limit is easy to bypass and unfair to shared networks. Rate limiting that works chooses the key well, learns normal behavior and escalates the response.

Cloudflare Rate LimitingAWS WAF rate-based rulesNGINX limit_reqEnvoy

What it is

restricts how many requests an entity can make in a time window. It protects against brute force, , scraping and resource exhaustion, and is one of the few defenses that work even when the attacker sends traffic that looks valid request by request.

Choosing the key is half the work

Limiting by IP is the starting point, but behind a corporate NAT or a mobile carrier thousands of legitimate users share the same IP, while an attacker with a botnet spreads traffic across thousands of IPs. The right key depends on what you are protecting:

  • IP: simple, good against crude abuse, bad with NAT and botnets.
  • Account or identifier in the body (for example, the user tried at login): catches an attack on one account coming from many IPs.
  • Token, cookie or session header: limits per authenticated client, not per network.
  • ASN, country or fingerprint: useful as an aggregator to detect coordinated waves.
  • Combinations (IP + path, account + ASN): reduce false positives.

Windows, limits and the response ladder

Instead of just blocking, escalate the response. A first excess gets a challenge, the second a short block and repeat offenders a longer block, always with an expiry (TTL) so one day's mistake does not become a permanent penalty.

rate limit rule - illustrativetext
# login: 10 attempts per minute per IP, and 5 per minute per account tried
match:   (http.request.method eq "POST" and http.request.uri.path eq "/api/login")
counting: per ip.src            -> 10 req / 60s
          per login username    ->  5 req / 60s   (custom characteristic)
response: 1st excess  -> Managed Challenge
          repeat      -> Block, timeout 600s

Adaptive: the limit follows normal

Fixed limits go stale: a marketing campaign doubles legitimate traffic and triggers blocks, and a patient attacker stays just under the limit. The adaptive approach uses the baseline of each endpoint and window (by hour and day of week) and alerts or acts when the deviation passes a threshold, using or .

In practice, the static limit remains as a safety ceiling and the adaptive one handles fine-grained behavior, always going through observation and shadow before blocking.

Where the limit should live

Ideally at the edge, before traffic costs processing at the origin. But some limits only make sense close to the application (per authenticated user, per tenant), where identity is already known. Each layer has its role, the subject of the topic.

Rate limitingLimit on requests per entity and time window. The choice of key (IP, account, token, ASN) matters as much as the limit value.see in glossary →Credential stuffingAttack that tests leaked username/password pairs from other services at scale. Signature: many login failures spread across many IPs, with few attempts per account.see in glossary →Z-scoreDistance of a value from the mean, measured in standard deviations. In detection, values far above the recent history of the same key suggest an anomaly.see in glossary →EWMAexponentially weighted moving averageAverage that gives more weight to recent data. Used as an adaptive baseline: it follows changes in normal traffic without getting stuck in the past.see in glossary →Defense in depthIndependent layers of protection, on the premise that any one of them can fail: validation + parameterization + WAF + monitoring.see in glossary →

connections on the map

updated on 14/10/2026 · sources to go deeper · report an error

Study before

Unlocks

test what you learned

Loading questions…