Rate limiting caps the number of requests a given source (an IP address, session, API key, or token) may make within a time window. It is a primary Layer 7 defensive control, one of the mechanisms a thorough DDoS test is built to validate under load, and it is easily misconfigured relative to real attack conditions.
How a rate limit actually counts
Every rate limit is three decisions: what it counts together, how it remembers, and what it does when the count crosses the line.
What it counts together is the aggregation key. Per source IP is the default, but a session cookie, an API token, or a forwarded client address are all common keys, and the key decides what an attacker has to rotate to slip past a limit.
How it remembers is the algorithm, and that choice changes the behaviour at the edges more than most operators expect. A fixed window counts requests per calendar interval and resets on the boundary. It is cheap, but it lets a client fire a full window's worth of requests just before the reset and again just after, briefly sustaining double the intended rate across the seam. A sliding window smooths that seam by weighting the previous interval into the current one.
A token bucket refills allowance at a steady rate and lets a client spend a saved burst all at once, which suits genuinely bursty but legitimate clients. A leaky bucket drains at a fixed rate instead and shapes traffic into a smooth stream, trading burst tolerance for predictability. And some limits count concurrent connections rather than request rate, which is the variant that actually bounds a slow-request attack, where the danger is held-open sockets rather than request volume.
None of these is more correct than the others. They fail differently, and a test that does not know which one is deployed cannot predict where a client will slip through.
Why it matters under attack
The value of a rate limit is that it caps the load any single source can put on the origin. Its limitation is the exact mirror of that value: it caps per source, so an attacker who spreads the same aggregate volume across enough sources keeps every individual key under the line and the limit never fires.
That is the shape of a carpet-bombing or distributed L7 flood. Thousands of addresses each send a handful of requests a second, none of them loud enough on its own to trip a counter, all of them together saturating the backend. A limit keyed per-IP is beaten by distribution, not by a higher rate.
The other quiet failure is mode. A limit sitting in count mode produces a clean dashboard of threshold crossings and blocks nothing, so a stack can believe it is protected while the traffic sails straight through.
Where the limit runs also decides what it can afford. A limit at the CDN edge sheds volume before it costs the origin anything. The same limit in application middleware only fires after the request has already consumed a worker and a database round trip, so the closer to the edge it sits, the cheaper the drop. Expressed as a concrete WAF object with its own console parameters, a rate limit becomes a rate-based rule.
What a DDoS test measures
A configured threshold is a claim about a number, and the algorithm decides how that number behaves at the edges, so a test checks both. It ramps a single source toward the limit and confirms the action engages near the configured rate rather than well above or below it, and it watches for the fixed-window seam where a client briefly holds double the intended rate across a reset.
It also confirms the limit is enforcing rather than only logging, and that legitimate bursts (a shared NAT egress, a busy mobile client, a flash crowd) are not swept up at the same line. The distribution question, how much source spread slides the same volume underneath a per-source counter, is what sets the control's real ceiling, and it is treated in depth for the concrete WAF object in rate-based rule. For where rate limiting sits among the application-layer controls under test, see Application-Layer (L7) DDoS Testing.