| name | security-review |
| description | Audit code or infrastructure for exploitable vulnerabilities using an OWASP-style checklist. Trigger when the user asks to "security review this", "is this safe to ship", "audit for vulnerabilities", "check for security issues", "pentest this", or before merging code that touches auth, payments, file uploads, or raw user input. Threat-models the surface first, then works a checklist by severity — reports exploit scenarios, not vague warnings. |
security-review
A security review answers: what can an attacker do, and what does it cost
them? Vague "this could be more secure" notes don't help anyone triage. For
every finding, state the concrete exploit scenario and its impact, ranked by
what actually gets exploited in practice.
1. Threat-model the surface first
- Who's the attacker? Anonymous internet user, authenticated user acting
against another user's data, or an insider/compromised dependency — the
bar for "exploitable" differs for each.
- What's the entry point? Every place untrusted data enters: HTTP request
bodies/headers/query params, file uploads, webhook payloads, queue
messages, CLI args, env vars from a less-trusted process, LLM tool output.
- What's worth stealing or breaking? Credentials, PII, payment data,
ability to impersonate another user, ability to run arbitrary code.
2. Injection — untrusted input reaching a sink
- SQL/NoSQL injection — string-concatenated queries. Fix: parameterized
queries / prepared statements, never build a query by interpolating input.
- Command injection — user input reaching a shell (
exec, system,
backticks). Fix: avoid the shell entirely (argv arrays, not a shell string);
allowlist if you truly need a shell.
- Path traversal — user-controlled filenames/paths reaching the
filesystem (
../../etc/passwd). Fix: resolve and verify the path stays
under an allowed root; never trust a client-supplied path segment.
