We get asked about scraper bots are getting better at pretending to be Chrome more than almost anything else, so here is the long answer.
Observability first
Every mitigation decision is logged with its reasons, and every log line can be traced to the rule and score components that produced it. When a customer asks why a request was challenged, the answer is a link, not a guess.
Logs stream to the customer’s SIEM within seconds, which also means their security team sees attacks in the same tools they use for everything else.
Why per-route baselines matter
A thousand requests per second to your homepage is Tuesday. A thousand requests per second to your password-reset endpoint is an attack. Global rate limits cannot tell the difference; per-route baselines can.
We learn the normal shape of traffic per route and per hour of the week, so a surge on a sensitive endpoint raises the risk score long before it approaches a global threshold.
Lessons for your own runbook
Know who can change DNS at two in the morning. Know your origin IPs and who can rotate them. Know which routes are expensive, and have a rate limit ready for each of them.
Most outages during attacks are not caused by the attack itself but by rushed changes made while under pressure.
What actually happens during a flood
The first thing to fail during a layer 7 flood is almost never bandwidth. It is connection slots, worker processes or database connections on the origin — resources measured in hundreds or thousands, not gigabits. An attacker who can make each request expensive only needs a few thousand requests per second.
That is why we score requests before they are proxied. By the time a request reaches your origin, it has been attributed to a client, compared against that client’s history and weighed against the current load on the route it targets.
Protecting the origin
None of this matters if the attacker can reach your origin directly. Historical DNS records, certificate transparency logs and misconfigured subdomains leak origin addresses all the time.
Allow-list the edge ranges, enable authenticated origin pulls and treat any origin IP that ever appeared in public DNS as burned.
Compliance is a side effect
Regulators increasingly ask for evidence of resilience, not just promises. An incident timeline with start, peak, vectors and impact is exactly the evidence DORA and NIS2 ask for — and it falls out of good observability for free.
We export incident reports in formats auditors can file without anyone rewriting them.
{ "match": { "path": "/login", "risk": ">= 46" }, "action": "challenge" }
As always, questions and corrections are welcome at [email protected].
We had the exact false-positive issue with CGNAT carriers. The weighting change makes sense.
Is the risk score exposed in the logs so we can build our own dashboards on it?
Clear and practical, thanks.
Great write-up. We saw almost the same pattern on our login endpoint last month.
The point about origin IPs leaking through certificate transparency logs is underrated.
Thanks! Yes — the risk score and its components are included in every log record.
Could you share the dataset behind the percentages?
Nice to read a vendor blog that admits what went wrong.
This matches what we see in iGaming around big matches.
Carpet bombing is nasty. Good to see a clear explanation of it.