# A06: Insecure Design

Last updated: March 1, 2026

## Findings addressed

1. Sensitive email-token workflows did not enforce a cooldown between repeated code requests.
2. Verification and account-deletion flows needed tighter, route-specific throttling to reduce brute-force and abuse risk.

## Fixes implemented

1. Added explicit email-token cooldown guard in API:
- New helper `assertEmailTokenCooldown(userId, type, cooldownMs)`.
- Throws structured `429` error with code `EMAIL_TOKEN_COOLDOWN`.
- Sets `Retry-After` header when cooldown is active.

2. Applied cooldown checks to both token issuance paths:
- `/auth/verify/resend` for signup verification codes.
- `/account/delete-request` for account deletion confirmation codes.

3. Split and applied stricter rate-limit profiles for sensitive auth/account routes:
- `authRateLimit` on `/auth/register` and `/auth/login`.
- `codeVerificationRateLimit` on `/auth/verify` and `/account/confirm-delete`.
- `codeIssueRateLimit` on `/auth/verify/resend` and `/account/delete-request`.

## Files changed

1. `api/src/server.ts`
2. `api/tests/insecure-design.test.ts`
3. `api/vitest.security.config.ts`

## Verification

Command:

```bash
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`:

1. Runtime verification resend endpoint enforces cooldown (`/auth/register` issues token, then immediate `/auth/verify/resend` is blocked with `429` + `Retry-After`).
2. Runtime verification delete-request endpoint enforces cooldown (`/account/delete-request` second attempt returns `429` + `Retry-After`).
3. Runtime verification repeated invalid `/auth/verify` requests trigger route throttling (`429`).

## Residual notes

1. A06 runtime tests require PostgreSQL availability for user/token persistence paths.