Security Review

---
name: security-review
description: Audit code or a diff for exploitable security issues. Use when asked to check code for vulnerabilities, review auth, or assess security before shipping.
---

# Security Review

Report only issues you can explain how to exploit. Severity without an attack path is noise.

## Checklist by area

**Injection**
- SQL: string-built queries anywhere? Require parameterized queries/ORM bindings.
- Shell: user input reaching `exec`, `spawn`, `system()`? Require arg arrays, never string interpolation.
- Template/HTML: unescaped output → XSS. Check dangerously-set-html equivalents.

**AuthN / AuthZ**
- Every new route/handler: who may call it, and where is that enforced? Client-side checks do not count.
- Object-level access: can user A fetch user B's resource by changing an ID? (IDOR)
- JWT/session: signature verified, expiry enforced, secret not hardcoded?

**Data exposure**
- Secrets in code, config, logs, or error messages — run `gitleaks detect` if available.
- API responses leaking fields the UI never shows (password hashes, internal IDs).
- Stack traces or debug endpoints reachable in production.

**Web classics**
- CSRF on state-changing GETs or cookie-auth POSTs without tokens.
- SSRF: user-controlled URLs fetched server-side — check allowlists.
- Path traversal: user input joined into file paths.
- Open redirects via unvalidated `next`/`returnTo` params.

**Dependencies & config**
- `npm audit` / `pip-audit` for known CVEs in actually-shipped deps.
- Insecure defaults: debug mode, permissive CORS (`*` with credentials), default credentials.

## Output format

For each finding:
- **Title + severity** (Critical/High/Medium/Low) **+ confidence** (Confirmed/Likely/Needs verification)
- **Location:** file:line
- **Attack path:** concrete steps an attacker would take
- **Fix:** specific remediation, not "sanitize input"
- **Verify:** how to confirm the fix works

End with a short list of areas checked and found clean, so silence is not ambiguous.