Reviews code for the security flaw classes that cause the most breaches - broken authorization and IDOR, injection, SSRF, mass assignment, and unsafe deserialization - and returns a short, focused findings list with concrete fixes. Use when someone asks "review this code for security issues", "is this endpoint safe", "check this PR for vulnerabilities", or is shipping auth logic, new API endpoints, file handling, or anything that touches untrusted input. Do NOT use for general code quality, style, or maintainability review - use code-review-checklist instead; for prioritizing findings a scanner already produced, use vulnerability-triage; for design-stage analysis before code exists, use threat-model-stride.
Click to play with sound.
---
name: Secure Code Review
description: Reviews code for the security flaw classes that cause the most breaches - broken authorization and IDOR, injection, SSRF, mass assignment, and unsafe deserialization - and returns a short, focused findings list with concrete fixes. Use when someone asks "review this code for security issues", "is this endpoint safe", "check this PR for vulnerabilities", or is shipping auth logic, new API endpoints, file handling, or anything that touches untrusted input. Do NOT use for general code quality, style, or maintainability review - use code-review-checklist instead; for prioritizing findings a scanner already produced, use vulnerability-triage; for design-stage analysis before code exists, use threat-model-stride.
---
# Secure Code Review
Secure code review is not a checklist audit - it is a focused search for the flaw categories that actually cause breaches. A 40-finding report gets skimmed and ignored; a 5-finding report where every item is exploitable gets fixed. The costly mistake this skill prevents is spending review time evenly across the diff while the one missing ownership check ships to production.
## Operating procedure
Work the steps in order: scope first, then the highest-breach-rate categories, then filtering, so scrutiny lands where risk lives.
### Step 1: Gather inputs
- The code under review: diff, PR, or file set.
- Entry points: which routes, handlers, jobs, or consumers accept untrusted input (request params, headers, cookies, body, queue messages, webhooks).
- Stack facts: framework, ORM or query layer, template engine, auth model (session, JWT, API key).
- Deployment context: internet-facing or internal, and whether the service runs in a cloud environment with an instance metadata endpoint.
- What changed and why, in one sentence - reviews without intent context miss logic flaws.
If entry points are unclear, trace them from the router or handler registry before reviewing anything, and label inferred entry points as guesses.
### Step 2: Budget scrutiny by risk
… install to load the full skill