insecure-design

Insecure Design Security Check (A06:2025)

What this checks

Catches security controls that were never designed in. Missing rate limiting, skippable workflow steps, and unenforced re-authentication enable account takeover, fraud, and privilege escalation.

Vulnerable patterns

• Credential-accepting endpoint (login, password reset, MFA verify) with no rate limit or lockout
• Multi-step workflow that advances based on a client-supplied step name or boolean rather than server-side state
• Authentication failure response that distinguishes "user not found" from "wrong password" via message text, status code, or timing
• Sensitive state change (email change, fund transfer, account deletion) protected only by session existence — no re-auth or step-up challenge
• Security-relevant decision (lockout status, role, authorization level) read from a request parameter, cookie, or header the client can freely modify

Fix immediately

Flag the vulnerable code and explain the risk. Translate the principles below to the audited file's language, web framework, and rate-limiter or session library — use that stack's documented middleware rather than rolling your own.

For each finding, establish these properties:

1. Every credential-accepting endpoint has a rate limit or lockout keyed on a caller-controlled identifier (IP, username, email, or account id). Apply to every such endpoint — login, password reset, MFA verify, token exchange, re-auth — not just login. Unlimited retries are never acceptable.
2. Authentication failure responses do not distinguish "user not found" from "wrong password" — same message, same status code, same timing. Always compute the password hash even when the user is missing (compare against a dummy hash to equalize latency); short-circuit branches leak account existence.
3. Sensitive state changes (password change, email change, fund transfer, account deletion, permission grant) require a check stronger than "session exists" — re-prompt for the current password, verify a step-up token, or require MFA.
4. Multi-step workflows read the current step from server-side state — session, database, or a signed token — never from a client-supplied parameter. The server owns the progression.
5. No security-relevant decision (lockout status, step progression, authorization level) is read from request parameters, cookies, or headers that the client can freely modify.