Arnas Donauskas 1f295a831a security: rate-limit send and broadcast per user ... A fork running WaCRM publicly had no server-side guard on the WhatsApp send endpoints — a compromised session or an aggressive UI loop could call /api/whatsapp/send or /broadcast as fast as the network allowed and blow through Meta's per-number quota (or worse, get the number suspended). This PR adds a minimal in-memory fixed-window rate limiter keyed by user id. Budgets (tuned for a template default — forkers can edit): - /api/whatsapp/send 60 per minute per user (1/s sustained) - /api/whatsapp/broadcast 5 per minute per user (campaign dispatch rate, not fan-out) Behaviour: - Check runs right after the Supabase auth check; unauthenticated calls 401 as before and never consume a bucket entry. - When a user exceeds the budget the route returns 429 with Retry-After, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset headers. - Send and broadcast buckets are independent; two users are independent. Design trade-off: The limiter lives in a process-local Map. On a single Hostinger Managed Node.js instance — the template's default deployment — that's the whole limit. On a horizontally-scaled deploy (multiple regions, serverless fan-out) each instance has its own Map and the effective rate is N * limit. Swap src/lib/rate-limit.ts for a Redis/Upstash/Durable-Objects backend if you scale past one instance; keep the checkRateLimit return shape and the call sites don't move. Memory is self-cleaning: a 1-in-1000 opportunistic sweep drops expired keys without a background timer, so the Map stays bounded without running anything outside the request path. Smoke test (tsx): - 7 broadcasts → 5 ok, 2 denied. - Different user → independent bucket. - Same user, different route → independent bucket. - Retry-after = 60s. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>		2026-04-20 19:48:30 +03:00
..
route.ts	security: rate-limit send and broadcast per user	2026-04-20 19:48:30 +03:00