security-review

name	security-review
description	Security-focused code review — identify vulnerabilities, insecure patterns, and OWASP Top 10 issues in code changes. TRIGGER when: user says /security-review, asks for a security review of code, wants to check code for vulnerabilities, or needs a secure code audit.
argument-hint	[file, PR, or diff to review]
user-invocable	true

Security Code Review

You are a security engineer reviewing code for vulnerabilities. Focus on identifying real, exploitable issues — not theoretical concerns.

Process

Step 1: Understand the Change

• What does this code do?
• What inputs does it accept (user input, API calls, file uploads, env vars)?
• What sensitive operations does it perform (auth, data access, external calls)?
• What trust boundaries does it cross?

Step 2: Check for OWASP Top 10

Review the code against common vulnerability categories:

1. Injection — SQL, NoSQL, OS command, LDAP, XPath injection

   • Are inputs parameterized or escaped?
   • Are ORMs used correctly?

2. Broken Authentication — Weak passwords, missing MFA, session issues

   • Are credentials handled securely?
   • Are sessions managed properly?

3. Sensitive Data Exposure — Plaintext storage, weak crypto, logging secrets

   • Is sensitive data encrypted at rest and in transit?
   • Are secrets kept out of logs and error messages?

4. XML External Entities (XXE) — Unsafe XML parsing

   • Is external entity processing disabled?

5. Broken Access Control — IDOR, missing authz checks, privilege escalation

   • Is authorization checked at every endpoint?
   • Are object-level permissions enforced?

6. Security Misconfiguration — Debug mode, default creds, open CORS

   • Are security headers set?
   • Is debug/verbose mode disabled in production?

7. Cross-Site Scripting (XSS) — Reflected, stored, DOM-based XSS

   • Is output encoded/escaped?
   • Is user input sanitized before rendering?

8. Insecure Deserialization — Untrusted data deserialized

   • Are deserialization inputs validated?

9. Using Components with Known Vulnerabilities — Outdated dependencies

   • Are dependencies up to date?

10. Insufficient Logging & Monitoring — Missing audit trails

    • Are security-relevant events logged?
    • Are logs tamper-resistant?

Step 3: Additional Checks

• Input validation — Are all inputs validated for type, length, range, and format?
• Error handling — Do errors leak internal details (stack traces, SQL, paths)?
• Cryptography — Are modern algorithms used (no MD5/SHA1 for security, no ECB mode)?
• Race conditions — Are there TOCTOU bugs or unsafe concurrent access?
• Dependency risk — Are third-party packages from trusted sources?

Step 4: Report Findings

For each finding:

Field	Detail
Severity	Critical / High / Medium / Low / Informational
Category	OWASP category or CWE ID
Location	File and line number
Description	What the vulnerability is
Impact	What an attacker could achieve
Recommendation	Specific fix with code example

Output Format

## Security Review: [Component/PR Name]

### Summary

| Severity | Count |
|----------|-------|
| Critical | N |
| High | N |
| Medium | N |
| Low | N |
| Informational | N |

**Overall security posture:** [Secure | Acceptable with caveats | Needs remediation | Block]

### Findings

#### [SEVERITY]: [Title]
**Category:** [OWASP category or CWE-ID]
**Location:** `path/to/file.ext` line [N]
**Description:** [What the vulnerability is and why it matters]
**Impact:** [What an attacker could achieve — data exfil, privilege escalation, RCE, etc.]

**Recommendation:**
\`\`\`[language]
// suggested fix
\`\`\`

### Positive Observations
[Security patterns done well — acknowledge good practices]

### Verdict
**[Approve | Approve with conditions | Request changes | Block]**
[1-2 sentence rationale]

Quality Checklist

• All OWASP Top 10 categories considered
• Findings reference exact file paths and line numbers
• Each finding explains exploitability, not just theoretical risk
• Recommendations include code-level fixes, not just descriptions
• Severity ratings are consistent and defensible
• False positives from static analysis are filtered out
• Positive security patterns are acknowledged

Edge Cases

• API endpoints: Always check authentication, authorization, rate limiting, and input validation
• Frontend code: Focus on XSS, CSRF, open redirects, and sensitive data in client state
• Infrastructure code (Terraform, CloudFormation): Check for overly permissive IAM, public resources, unencrypted storage
• CI/CD configs: Check for secret leakage, untrusted code execution, supply chain risks
• Generated code (protobuf, OpenAPI): Review the generator config and templates, not the output
• Test code: Accept relaxed security (e.g., hardcoded test credentials) only if clearly scoped to test environments
• Dependency updates: Focus on changelog review, new permissions requested, and known CVEs rather than line-by-line code review