HTTP flood: valid requests that take a whole site down

That qualifier is the whole subject of this page. Defence works on aggregate behaviour, because no individual request is distinguishable from one a customer would send.

Requests that only read are the cheaper form for the sender: no body to construct, no session to maintain. Their effectiveness depends entirely on choosing paths that cost you something, which is why an attack on a search or a filtered listing does more damage than one on a static page.

Requests that submit are more expensive for both sides. They force parsing, validation, and often a write, and writes are the operations least able to be scaled away by caching or read replicas. A modest rate against a submission endpoint can outweigh a much larger rate against a page that only reads.

The choice between them tells you something about the sender's intent: a flood aimed at reads is usually about volume, while one aimed at writes is usually about finding your most expensive operation.

A request carries a method, a path, headers, and possibly a body. Every one of those fields can hold exactly what a browser would send, because there is nothing preventing it.

One consequence is where most defensive effort is wasted: any rule that describes what a bad request looks like will either miss traffic that copies a browser or block customers whose requests happen to match. The distinguishing information does not exist inside a single request. It exists across many of them.

The evidence is in the shape of traffic rather than in its contents.

Four properties separate the two kinds of line above.

Path concentration. Real populations spread across a site. A flood concentrates, usually on whatever is expensive.

Uniform timing. Human traffic is irregular: people read, pause, and leave. Generated traffic tends toward even intervals unless deliberately varied.

Missing context. Requests arriving without the accompanying assets a page would load, or without the referrer chain that browsing produces, are not browsing.

Population uniformity. A client base that all announces itself identically, or that all appeared within the same minute, is not a client base.

The signal everyone over-trusts

A single repeated User-Agent string looks conclusive and is not.

That header is set by whoever sends the request, so it proves nothing on its own: it can copy a current browser exactly, and it frequently does. Meanwhile a genuine population contains large groups sharing identical strings, because that is what a popular browser version looks like.

Treat it as one weak input among several. Blocking on it alone is a decision that removes real visitors and stops working the moment the sender changes one line.

Requests at scale usually originate from many compromised or rented machines rather than from one place, which is why source-based blocking runs out quickly: each address contributes little, and there are many.

That property is the reason limits work better per client than in aggregate, and the reason challenges matter: they ask each source to spend something, and the economics of the attack depend on each source being cheap.

Four measures, and unlike the other families these are yours to apply.

Limit per endpoint, not just per site. The expensive path deserves a tighter allowance than the cheap one, and a single global rate either throttles normal browsing or leaves the expensive path unprotected.

Challenge before blocking. Asking a client to demonstrate it is a browser separates populations without denying anyone outright, and it costs far less in false positives than a block.

Cache what can be cached. A request served from cache removes the lever entirely. Attacks concentrate on what cannot be cached precisely because of this.

Bound the expensive operations. Limiting what a search may return or what a report may span reduces the cost per request, which changes the rate at which an attack becomes viable.

Check this before any of the above: the response differs and the symptoms do not.

A campaign that worked, a link that spread, or a partner sending traffic they did not warn you about all produce a sudden concentration of requests on a few paths. So does a search engine indexing a section it had not seen before. Each looks like an attack in every graph you have, and each is revenue rather than an emergency.

Two checks usually settle it. Look at whether the traffic converts or behaves like people once it arrives: real visitors load assets, follow links, and leave in a distribution. And look at whether the sources have histories, since a population that existed yesterday is different from one that appeared at once.

Every measure here can refuse a customer.

Address-based limits misfire where many people share one address, which is normal on mobile networks and in offices. Challenges break the automation you asked for: monitoring, payment callbacks, and integrations. Rules written during an incident stay in place afterwards and quietly remove traffic nobody is watching.

The rule that holds: measures should expire on their own, and where a decision is uncertain, slowing a client is safer than refusing it. A delay annoys a customer; a block loses one.

This is the layer Bridge WAF exists for. Requests are inspected before reaching your origin, rate limiting is applied per domain, and abusive patterns are handled without writing a rule for each variation. Requests that never arrive cost your servers nothing. What this does not address is traffic that saturates a link, which belongs to a different layer entirely. See what the platform offers at Bridge CDN.