Skip to content

Add rate limit to the sync Worker - #8

Open
carolinevrauwdeunt-lab wants to merge 1 commit into
mainfrom
add-worker-rate-limit
Open

Add rate limit to the sync Worker#8
carolinevrauwdeunt-lab wants to merge 1 commit into
mainfrom
add-worker-rate-limit

Conversation

@carolinevrauwdeunt-lab

Copy link
Copy Markdown
Contributor

Adds a Cloudflare Rate Limiting binding to /notes (30 req/min per IP) — a free, defense-in-depth layer requested "just in case" someone starts probing deployed Worker URLs.

Honest framing, not oversold: tested this against the live deployment. Normal traffic passes through fine. But a fast burst (100+ requests in well under a minute) did not reliably trip the limit — confirmed via debug headers that every request genuinely reached fresh Worker code (ruled out caching, IP rotation, middleware not running). This matches Cloudflare's own docs, which describe the Rate Limiting binding as "eventually consistent" and enforced per-isolate/per-datacenter rather than with a single global counter — explicitly "not suited for strict abuse prevention."

So this ships as what it actually is: free and harmless, adds some friction, but the real defense against brute-forcing API_KEY remains its length (a 256-bit random string per the existing setup steps) — documented plainly in both the code comment and worker/README.md rather than implying a guarantee that doesn't hold up.

No extra setup for OSS users — namespace_id in the [[ratelimits]] block is just an arbitrary account-unique number, not something requiring provisioning like the KV namespace does.

🤖 Generated with Claude Code

A free, harmless extra layer on /notes (30 req/min per IP via Cloudflare's
Rate Limiting binding), added defense-in-depth against anyone probing a
discovered Worker URL. No provisioning needed for it (namespace_id is just
an account-unique number you pick, unlike KV).

Tested against the live deployment: normal traffic passes through
untouched, confirmed. Also tested whether it reliably blocks a fast burst
(100+ requests) — it did not, consistent with Cloudflare's own
documentation describing this binding as "eventually consistent" and
enforced per-isolate rather than with a single global counter. Documented
this honestly in both the code comment and the README rather than
overselling it: the real protection against brute-forcing API_KEY is
already its length (256-bit random string, per the existing setup
instructions), not this binding.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant