The easiest mistake a security product makes is believing its own success. It shows the number of blocked requests, the graphs go up, everyone is pleased. What stays invisible is this: how many real customers were inside that number?
The design rule of this project is one sentence: a false positive is worse than a missed attack. A blocked customer costs more than a bot that got through — both as direct revenue and because they do not come back.
The shared egress problem
Rate limits measure per IP. That rests on "one IP equals one user", and that assumption is often wrong:
- On mobile networks, dozens of users leave through the same CGNAT address
- An office, a school, a hotel: hundreds of devices behind one public IP
- If you use a CDN, all of your traffic arrives from a few hundred edge addresses
In a 50-person office, everyone opening one page every five seconds is 50 requests. With a threshold of 45, everyone in that office gets thrown off. No attacker, no attack — just a bad threshold.
What we changed
During an audit we found four separate places where a rule the panel described as "rate limits" actually threw the IP off the whole site for 5–10 minutes:
| Rule | Old behaviour | New behaviour |
|---|---|---|
| Sensitive path shield | 10 min site-wide ban | 429 on that path only |
| POST flood shield | 5 min site-wide ban | 429 on that POST only |
| 60s sustained load | 10 min ban | Verify once |
| 5s burst | Immediate ban | Verify first, ban on 3rd |
That last row matters most. The first time the limit is exceeded the visitor is asked to verify. A real browser passes without noticing, receives clearance and moves to the verified threshold (200 requests per 5 seconds) — so it never hits this again. A typical bot cannot pass, keeps hitting the same window, and a client that hits it three times in 60 seconds is by definition a persistent unverifiable flood. That one gets banned.
The price of a false positive went from a ten-minute blackout to a one-second delay.
How we test it
Writing "this no longer bans" is not enough; it has to be proven on every release. The test suite locks in:
- A visitor opening 2 pages per second for 60 seconds is not even sent to verification — well above human speed, still untouched.
- The sensitive path limit does not ban the IP site-wide — after 60 POST attempts the ban table must be empty.
- Pipelining detection behind a CDN drops nothing — 400 requests, zero drops.
- The sustained window verifies instead of blocking — the 444/429 count must be zero.
These tests are not written once and forgotten; they run after every change. Next time someone says "let's tighten this a little", the test that turns red tells them exactly what the tightening costs.