Arnas Donauskas 01715c7d6d feat(api): per-user rate limits on admin account endpoints ... Addresses the L1 finding from the final security review. The six admin-class write endpoints under /api/account had no rate limits, so a compromised admin session (or a script run in a loop) could spam invite creation / role flips / member removes fast enough to flood the DB or audit logs. Adds a new `RATE_LIMITS.adminAction` bucket — 30/min/user — and wires it into: - POST /api/account/invitations → admin:inviteCreate - DELETE /api/account/invitations/[id] → admin:inviteRevoke - PATCH /api/account/members/[userId] → admin:memberRole - DELETE /api/account/members/[userId] → admin:memberRemove - POST /api/account/transfer-ownership → admin:transferOwnership - PATCH /api/account → admin:rename Each endpoint keys its own bucket so spamming one doesn't starve another. 30/min is comfortably above any realistic human pace (the Members tab is a clicks-only UI; a legit admin would struggle to hit ten of these per minute by hand) while still bounding accidental abuse. The bucket joins the existing send / broadcast / react / invitationPeek / invitationRedeem buckets in `RATE_LIMITS` — same in-memory fixed-window limiter, same `rateLimitResponse` helper for the 429 shape. Severity in the final review: LOW. The admin-trust model means this isn't blocking — but the cost of adding it is six near-identical 4-line additions and zero net risk, so worth landing for hardening. Verification - `npm run lint` → 0 errors (same 19 pre-existing warnings) - `npm run typecheck` → clean - `npm test` → 366/366 pass Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>		2026-06-01 15:05:49 +03:00
..
route.ts	feat(api): per-user rate limits on admin account endpoints	2026-06-01 15:05:49 +03:00