/security-review

name: security-review
description: Security code review for vulnerabilities. Use when asked to "security review", "find vulnerabilities", "check for security issues", "audit security", "OWASP review", or review code for injection, XSS, authentication, authorization, cryptography issues. Provides systematic review with confidence-based reporting.
allowed-tools: Read Grep Glob Bash Task
license: LICENSE

<!-- Reference material based on OWASP Cheat Sheet Series (CC BY-SA 4.0) https://cheatsheetseries.owasp.org/ -->

Security Review Skill

Identify exploitable security vulnerabilities in code. Report only **HIGH CONFIDENCE** findings—clear vulnerable patterns with attacker-controlled input.

Scope: Research vs. Reporting

**CRITICAL DISTINCTION:**

• **Report on**: Only the specific file, diff, or code provided by the user
• **Research**: The ENTIRE codebase to build confidence before reporting

Before flagging any issue, you MUST research the codebase to understand:

• Where does this input actually come from? (Trace data flow)
• Is there validation/sanitization elsewhere?
• How is this configured? (Check settings, config files, middleware)
• What framework protections exist?

**Do NOT report issues based solely on pattern matching.** Investigate first, then report only what you're confident is exploitable.

Confidence Levels

| Level | Criteria | Action | |-------|----------|--------| | **HIGH** | Vulnerable pattern + attacker-controlled input confirmed | **Report** with severity | | **MEDIUM** | Vulnerable pattern, input source unclear | **Note** as "Needs verification" | | **LOW** | Theoretical, best practice, defense-in-depth | **Do not report** |

Do Not Flag

General Rules

• Test files (unless explicitly reviewing test security)
• Dead code, commented code, documentation strings
• Patterns using **constants** or **server-controlled configuration**
• Code paths that require prior authentication to reach (note the auth requirement instead)

Server-Controlled Values (NOT Attacker-Controlled)

These are configured by operators, not controlled by attackers:

| Source | Example | Why It's Safe | |--------|---------|---------------| | Django settings | `settings.API_URL`, `settings.ALLOWED_HOSTS` | Set via config/env at deployment | | Environment variables | `os.environ.get('DATABASE_URL')` | Deployment configuration | | Config files | `config.yaml`, `app.config['KEY']` | Server-side files | | Framework constants | `django.conf.settings.*` | Not user-modifiable | | Hardcoded values | `BASE_URL = "https://api.internal"` | Compile-time constants |

**SSRF Example - NOT a vulnerability:**

# SAFE: URL comes from Django settings (server-controlled)
response = requests.get(f"{settings.SEER_AUTOFIX_URL}{path}")

**SSRF Example - IS a vulnerability:**

# VULNERABLE: URL comes from request (attacker-controlled)
response = requests.get(request.GET.get('url'))

Framework-Mitigated Patterns

Check language guides before flagging. Common false positives:

| Pattern | Why It's Usually Safe | |---------|----------------------| | Django `{{ variable }}` | Auto-escaped by default | | React `{variable}` | Auto-escaped by default | | Vue `{{ variable }}` | Auto-escaped by default | | `User.objects.filter(id=input)` | ORM parameterizes queries | | `cursor.execute("...%s", (input,))` | Parameterized query | | `innerHTML = "<b>Loading...</b>"` | Constant string, no user input |

**Only flag these when:**

• Django: `{{ var|safe }}`, `{% autoescape off %}`, `mark_safe(user_input)`
• React: `dangerouslySetInnerHTML={{__html: userInput}}`
• Vue: `v-html="userInput"`
• ORM: `.raw()`, `.extra()`, `RawSQL()` with string interpolation

Review Process

1. Detect Context

What type of code am I reviewing?

| Code Type | Load These References | |-----------|----------------------| | API endpoints, routes | `authorization.md`, `authentication.md`, `injection.md` | | Django/DRF views, permission classes, object-level access | Use the `django-access-review` skill if available for access control; otherwise `authorization.md` | | Frontend, templates | `xss.md`, `csrf.md`, `modern-threats.md` (DOM clobbering, prototype pollution) | | File handling, uploads | `file-security.md` | | Crypto, secrets, tokens | `cryptography.md`, `data-protection.md` | | Data serialization | `deserialization.md` | | External requests | `ssrf.md` | | Business workflows | `business-logic.md` | | GraphQL, REST design | `api-security.md` | | Config, headers, CORS | `misconfiguration.md` | | CI/CD, dependencies | `supply-chain.md` | | Error handling | `error-handling.md` | | Audit, logging | `logging.md` | | Object merging/cloning, `__proto__`, DOM `id`/`name` lookups, WebSocket handlers, LLM prompt construction | `modern-threats.md` |

2. Load Language Guide

Based on file extension or imports:

| Indicators | Guide | |------------|-------| | `.py`, `django`, `flask`, `fastapi` | `languages/python.md` | | `.js`, `.ts`, `express`, `react`, `vue`, `next` | `languages/javascript.md` |

For other languages there is no dedicated guide; rely on the `references/` files and verify framework protections directly in the codebase.

3. Load Infrastructure Guide (if applicable)

| File Type | Guide | |-----------|-------| | `Dockerfile`, `.dockerignore` | `infrastructure/docker.md` | | GitHub Actions workflows | Use the `gha-security-review` skill if available; otherwise `references/supply-chain.md` | | Other CI/CD pipelines, lockfiles, package manifests | `references/supply-chain.md` |

4. Research Before Flagging

**For each potential issue, research the codebase to build confidence:**

• Where does this value actually come from? Trace the data flow.
• Is it configured at deployment (settings, env vars) or from user input?
• Is there validation, sanitization, or allowlisting elsewhere?
• What framework protections apply?

Only report issues where you have HIGH confidence after understanding