A customer reported this last week: when the attack starts, CPU jumps to 100% and the site goes down — but the request count is not remarkable. The traffic graph showed a few hundred requests per second, the same as a normal news site at lunchtime.
The shape of the attack was this:
GET /products?x=81723 HTTP/1.1
GET /products?x=99120 HTTP/1.1
GET /products?x=41088 HTTP/1.1
GET /products?x=70551 HTTP/1.1Why it works so well
Edge caching keys on the URL. /products?x=81723 and /products?x=99120 are, as far as the cache is concerned, two different pages. Because the attacker changes the query on every request, the hit rate drops to zero and every request reaches the origin.
On the origin side that URL is probably a product listing: a database query, a few joins, maybe a pagination count. The attacker's cost is one line of text; yours is a full query. The ratio is one to ten thousand.
In a volumetric attack the defence's job is to stop packets. In a query-string flood the job is to stop the expensive work — there were never many packets to begin with.
Why per-IP rate limiting is not enough
A per-IP limit measures how much one address sends. Distributed across a botnet, each address looks innocent: two or three requests a second. No sensible threshold catches that — and a threshold low enough to catch it starts blocking real users.
What needs measuring is not the address but the path itself. How many distinct queries per minute is normal for /products? On search and filter pages that number is high, but it has a ceiling.
What HexShield does
Unverified requests that carry a query string are counted per normalized path in a 10-second window. Over the threshold, unverified visitors to that path are asked to verify.
Two things happen at once:
- A real visitor passes verification in under a second, receives the clearance cookie and never hits this rule again.
- A typical attack tool does not solve the proof-of-work, so it does not reach the origin and no database query is opened.
The threshold is deliberately high: 500 requests in 10 seconds, one path, unverified traffic only. Search engines are exempt — on-site search pages get crawled with query strings and that should not damage rankings.
And then there is global pressure
Here is the subtle part: issuing a verification page is itself a cost. On a 50,000-address botnet, "show each address a verification page" means producing 50,000 pages.
So the edge measures the unverified request rate globally. Above a threshold it switches to a cheap mode: expensive scans are skipped, no verification pages are produced, and requests over the line are dropped by closing the connection. A 444 response produces nothing — no body, no log line.
Making sure the defence does not amplify the attack is the part most often skipped. A protection layer must never take down the site it protects.