Detects missing security controls — rate limits, MFA, re-auth — that should have been designed in from the start. Use when designing authentication flows, implementing rate limiting, building business logic for financial or access-sensitive operations, or writing code that enforces security requirements at the application layer.
Installation
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Detects missing security controls — rate limits, MFA, re-auth — that should have been designed in from the start. Use when designing authentication flows, implementing rate limiting, building business logic for financial or access-sensitive operations, or writing code that enforces security requirements at the application layer.
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:
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.
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.
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.
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.
No security-relevant decision (lockout status, step progression,
authorization level) is read from request parameters, cookies, or headers that
the client can freely modify.
Verification
Confirm these properties hold for every endpoint present (language-agnostic;
criteria apply only to patterns actually present):
Every credential-accepting endpoint present (login, password reset, MFA verify, token exchange) is gated by at least one rate-limiting or lockout mechanism keyed on a caller-controlled identifier (IP, username, email, or account id) — unlimited retries are not permitted
Authentication failure responses do not distinguish "user not found" from "wrong password" via message text, status code, or response timing
Any sensitive state-change operation present in the code (password change, email change, fund transfer, account deletion, permission grant) performs an authorization check stronger than "session exists" — e.g., re-prompts for the current password, verifies a step-up token, or requires an MFA challenge
Multi-step workflows present in the code determine the current step from server-side state (session, database, signed token), not from a client-supplied step name, token, or boolean
No security-relevant decision (lockout status, step progression, authorization level) is read from request parameters, cookies, or headers that the client can freely modify
