How it works
Automation requests routes whose processing is expensive relative to the request itself, or deliberately varies the request so that a cache cannot serve it and every one reaches the origin.
The asymmetry moved up the stack
Network-layer floods work by sending more bits than a circuit can carry. Layer-7 floods work by sending requests that are cheap to produce and expensive to answer, which means they can succeed at traffic volumes that never trouble the network at all.
A request costing an attacker a few hundred bytes might cost the origin a template render, several database queries and a call to a downstream service. At a few thousand requests per second — trivial for a modest botnet and invisible on a bandwidth graph — that is enough to saturate a connection pool or exhaust worker processes.
This is why network mitigation frequently reports nothing during an application-layer incident. The circuit is fine. The scrubbing service sees ordinary volume. The application is nonetheless unable to answer, and the only place the attack is visible is in metrics owned by the application team.
Why caching is the primary control, and why attackers target it
A cached response costs almost nothing. If the edge answers, the origin never sees the request, and the attack has to defeat a system built for exactly this volume. Caching is therefore not a performance optimisation with a security side effect — for this attack class it is the main defence.
Attackers know this, which is why cache-bypass is the natural evolution of a request flood. Anything that makes each request unique forces a miss: an appended random query parameter, a varying header the cache keys on, a path that differs only in case or trailing separator.
The defence is disciplined key normalisation. Decide explicitly which inputs may change a response, strip everything else before the key is computed, and normalise path and case so two spellings cannot occupy separate entries. A cache that keys on the full query string will serve nothing during a cache-buster attack; one that keys only on parameters the application actually reads is largely immune.
Request collapsing matters equally. When many requests for the same uncached object arrive at once, the edge should fetch once and satisfy all of them from that single result, rather than passing every one through and multiplying the load it was meant to absorb.
Not all routes cost the same
Uniform rate limiting misallocates protection, because request cost varies by orders of magnitude across a single application. A static asset and a search query with wildcards and sorting are both "one request" to a counter and are not remotely comparable to the origin.
Rank routes by what they consume, then limit accordingly. Search, report generation, export, anything that fans out to several downstream services, and anything performing cryptographic work deserve tighter budgets than ordinary page views. A limit generous enough to be invisible on a cheap route is far too generous on an expensive one.
This exercise also tends to surface routes nobody realised were expensive — an endpoint that looks trivial but issues a query without an index, or one that quietly calls a third-party API on every request and inherits that provider's rate limit as an availability dependency.
Autoscaling cuts both ways
Automatic scaling is frequently described as DDoS resilience and is better understood as a choice about which failure you prefer.
Scaling into an application-layer flood absorbs it, keeps the service available, and bills you for capacity consumed entirely by an attacker. Against a sustained campaign that can become the more damaging outcome, and there are documented cases of scaling costs exceeding what an outage would have cost.
Set upper bounds deliberately rather than leaving them at whatever the platform defaults to, and alert on scaling events rather than treating them as routine. A scale-out at three in the morning with no corresponding business activity is a security signal, not a capacity one.
Detection
Application floods hide in metrics that look plausible in isolation, so the useful signals are ratios and distributions.
- Cache hit ratio per route. A sudden fall is the clearest single indicator of a bypass attack.
- Requests per second against origin CPU — a rising ratio of cost per request means the mix has shifted toward expensive routes.
- Cardinality of query strings and paths. Genuine traffic reuses a bounded set; cache-busting explodes it.
- Request composition. Real users fetch a page and its assets in recognisable sequences; automation usually hits one endpoint with no supporting requests.
- Client uniformity — TLS fingerprint, header ordering and capability support clustering far more tightly than a real browser population.
- Connection and worker pool utilisation, which saturates before error rates rise and therefore gives earlier warning.
Also known as
What defenders may observe
- Requests per second or concurrency exceeds baseline without a business explanation
- Origin CPU, worker pools or database connections saturate while bandwidth stays modest
- Cache hit ratio falls sharply
- Unique URLs or query-string variants surge
- Many clients share automation traits despite differing addresses
Prevention and mitigation
- Cache aggressively and normalise cache keys so irrelevant variation cannot force a miss
- Apply rate limits weighted by the cost of the route, not uniformly
- Keep the origin unreachable except through the edge
- Shield the origin with request collapsing so one miss does not become many
- Be deliberate about autoscaling — scaling into an attack converts an outage into a bill
- Use application-aware DDoS controls at a CDN or reverse proxy
Initial response priorities
- Activate application-aware edge controls and origin shielding.
- Identify the expensive route, query or protocol behavior.
- Challenge, rate-limit or shed abusive work while preserving normal users.
Use your approved incident-response plan and adapt decisions to your environment. This is educational guidance, not a substitute for live incident leadership.