1.8 KiB
1.8 KiB
A06: Insecure Design
Last updated: March 1, 2026
Findings addressed
- Sensitive email-token workflows did not enforce a cooldown between repeated code requests.
- Verification and account-deletion flows needed tighter, route-specific throttling to reduce brute-force and abuse risk.
Fixes implemented
- Added explicit email-token cooldown guard in API:
- New helper
assertEmailTokenCooldown(userId, type, cooldownMs). - Throws structured
429error with codeEMAIL_TOKEN_COOLDOWN. - Sets
Retry-Afterheader when cooldown is active.
- Applied cooldown checks to both token issuance paths:
/auth/verify/resendfor signup verification codes./account/delete-requestfor account deletion confirmation codes.
- Split and applied stricter rate-limit profiles for sensitive auth/account routes:
authRateLimiton/auth/registerand/auth/login.codeVerificationRateLimiton/auth/verifyand/account/confirm-delete.codeIssueRateLimiton/auth/verify/resendand/account/delete-request.
Files changed
api/src/server.tsapi/tests/insecure-design.test.tsapi/vitest.security.config.ts
Verification
Command:
cd api
npx vitest --run -c vitest.security.config.ts
Verified output:
- Test Files:
4 passed (4) - Tests:
10 passed (10)
Dedicated A06 checks in insecure-design.test.ts:
- Runtime verification resend endpoint enforces cooldown (
/auth/registerissues token, then immediate/auth/verify/resendis blocked with429+Retry-After). - Runtime verification delete-request endpoint enforces cooldown (
/account/delete-requestsecond attempt returns429+Retry-After). - Runtime verification repeated invalid
/auth/verifyrequests trigger route throttling (429).
Residual notes
- A06 runtime tests require PostgreSQL availability for user/token persistence paths.