public signup and a password reset endpoint on a worker, both currently unprotected, and someone spent last tuesday evening hammering the reset one. i want something that stops abuse without me writing an accounting system. i've read that the rate limit binding is per location, which sounds like it means a determined person just gets a fresh bucket in every city.
Which is why I'd split it by what you're actually defending.
Abuse and noise — the flood, the scraper, the script kiddie — goes to the binding, or to a WAF rate limiting rule in front of the worker so the request never costs you any CPU at all. Business rules — this account may request three resets a day — need to be accurate and global, and that's a durable object keyed by email, or a row in D1 with a counter and a timestamp.
Trying to make one mechanism do both is how people end up writing an accounting system, which is the thing you said you didn't want to do.
That distinction saves people a lot of wasted work. Abuse defence can be approximate and cheap; product rules have to be exact and cost you a round trip.
splitting it by what i'm defending is the framing i was missing. the reset flood is an abuse problem and 'three resets per day per account' is a product rule, and i'd been trying to solve both with one counter.
KV is the wrong tool here and I learned it the expensive way. Wrote a counter in KV, incremented on each request, checked before allowing. It looked fine in testing with me clicking.
Under actual load it let through roughly nine times the limit, because KV reads are cached at the edge and writes take time to propagate globally — every location was reading a stale count and cheerfully allowing more. It's not a bug, it's what KV is for, and I'd used it as a mutex. Durable objects exist precisely because that doesn't work.
this was going to be my monday plan, so thank you for taking the bullet. i had it in my head that kv was just a fast small database.
Fast small database with eventual consistency, which is a fine description right up until two writers care about the same key at the same moment.
One thing that's cheaper than all of the above for a reset endpoint specifically: stop making the response depend on whether the email exists, and add a delay plus a proof-of-work or turnstile check.
Most of the value in hammering a reset endpoint is enumeration. Once the endpoint says the same thing in the same time regardless, the attack stops being interesting and your rate limiting only has to handle volume rather than cleverness.
Binding for the flood, durable object for the rule, WAF in front if you want it to cost nothing. Ten or sixty seconds only, per location, eventually consistent — design for that and it's genuinely enough for signup abuse.
@borrowck_ben · 5mo ago
Your reading is right and it matters less than you think. The docs are upfront: limits are local to the Cloudflare location your worker runs in, there's a separate limit per key per location, and the whole thing is described as permissive, eventually consistent and deliberately not an accurate accounting system.
So yes, in theory an attacker distributed across twenty locations gets twenty buckets. In practice the person hammering your reset endpoint on a Tuesday evening is coming from one place, and the binding stops them with about six lines of config. The other constraint to know before you design around it: the period must be either 10 or 60 seconds. Nothing longer. If you wanted "5 resets per hour per email," that binding cannot express it.
Reply
Report