Why Rate Limiting Alone Never Stops a Distributed Bot Attack

What rate limiting is good at

Rate limiting is a volume control, and it is good at its job. One IP hammering a login endpoint, a scraper pulling every product page in sequence, a credential stuffing burst from a single address: the limit fires, the 429s go out, and the attack stops. It is simple, cheap, and it works on exactly the threat it was built for, a single source making too many requests.

The problem is that the threat moved. Modern bot attacks do not come from one IP. They come from thousands of residential IPs, each making a reasonable number of requests, each staying comfortably under any limit a store can set without blocking real shoppers. The limit watches the door for a flood and the attack walks in as a crowd.

The residential proxy problem

A residential proxy network rents IP addresses that belong to real homes and devices. Traffic routed through it looks like ordinary household traffic, because in a sense it is: the packets come from real consumer connections. A bot operator who rents ten thousand of these addresses can spread an attack so thin that no single IP ever looks abusive. Each one makes a handful of requests, waits, and moves on.

This is why IP reputation decays as a defense. The BADBOX 2.0 botnet, investigated by Krebs on Security, runs on compromised devices in real homes, so its traffic carries the reputation of ordinary consumers. Blocking the IPs means blocking the households. The attack hides in the one place a rate limit cannot look: the identity of the visitor, rather than the volume of the visits.

What has to sit next to the limit

A limit needs a behavior layer beside it. Watch what the visitor does, not how often it knocks: mouse movement that never varies, pages loaded in exact sequence, requests that skip the images and scripts a real browser always fetches, TLS fingerprints that match a headless browser rather than Chrome. Any one of these is weak evidence. Together they separate a distributed attack from a busy hour.

Then put the challenge where it costs the bot, not the shopper. A managed challenge on the login and checkout paths, rate limits on the API endpoints, and WAF rules that look for the behavior pattern rather than the IP count. The limit stays, because it still catches the flood. It just stops being the whole defense, which is the mistake: treating a volume control as if it were a bot detector.

Keep reading: Why Real Users Fail CAPTCHA and Bots Pass It, Headless Browsers vs Real Browsers: How Bot Detection Tells Them Apart.