choosing between DNS delegation and CNAME onboarding sounds like a narrow topic. It turns out to touch almost every part of how an edge network behaves under attack.
Challenges beat blocks
Blocking lists go stale within minutes when attackers rotate through residential proxies. Proof-of-work does not care where a request comes from; it only cares whether the client is willing to pay the cost.
For a real browser that cost is a few hundred milliseconds, once per session. For a botnet sending a million requests a minute it is a million puzzles a minute — and at that point the attack stops being cheap.
What we got wrong
Our first version challenged too eagerly on mobile networks, where thousands of real users share a handful of carrier-grade NAT addresses. Reputation that is shared is reputation that is noisy.
We now weight fingerprint consistency and session behaviour far more heavily than IP reputation for traffic from known mobile carrier ranges.
Latency budget
Our budget for the whole filtering pipeline is one millisecond at the 99th percentile. Anything that cannot be decided within that budget runs asynchronously and influences the next request from the same client, not the current one.
That constraint shapes everything: data structures, where state lives and which signals we are willing to compute inline.
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.
The full incident data behind this post is available to customers in the dashboard under Reports.
Great write-up. We saw almost the same pattern on our login endpoint last month.
Is the risk score exposed in the logs so we can build our own dashboards on it?
We had the exact false-positive issue with CGNAT carriers. The weighting change makes sense.
Verified good bots and allow-listed partners bypass challenges entirely.
We had the exact false-positive issue with CGNAT carriers. The weighting change makes sense.
This matches what we see in iGaming around big matches.
Verified good bots and allow-listed partners bypass challenges entirely.
Would love a follow-up on how you handle HTTP/3 fingerprinting.
Is the risk score exposed in the logs so we can build our own dashboards on it?
Thanks — sharing this with our on-call team.