/owasp-security

name: owasp-security
description: Reviews code for security vulnerabilities and guides secure implementation using OWASP Top 10:2025, ASVS 5.0, the OWASP Top 10 for LLM Applications (2026), and the OWASP Top 10 for Agentic Applications (2026). Use when reviewing code or a diff for security issues, implementing authentication, authorization, sessions, or cryptography, handling untrusted input, files, or URLs, hardening config, dependencies, or CI, or building LLM and AI agent features.
when_to_use: Trigger phrases include "security review", "security check", "anything exploitable", "audit this", "is this secure", "is this safe to ship", "check for vulnerabilities", "find security bugs", "threat model", "OWASP", "ASVS", "CWE", "prompt injection", "MCP server security", "secrets in code", "supply chain", and "harden this Dockerfile or workflow".

OWASP Security

Apply these standards when writing or reviewing code. For a review, follow the workflow below.

**Reference files** (read the one the task needs, and only the section you need):

• [`reference/review-checklist.md`](reference/review-checklist.md): coverage checklist for every Top 10 category, plus LLM and agent checks. Read during step 3 of a review.
• [`reference/languages.md`](reference/languages.md): per-language pitfalls with unsafe/safe examples for 20+ languages. Read the section for the language under review.
• [`reference/config-and-supply-chain.md`](reference/config-and-supply-chain.md): A02 and A03 in Dockerfiles, Kubernetes, Terraform, framework config, security headers, lockfiles, and CI/CD. Read when the change touches config, IaC, dependencies, or pipelines.
• [`reference/owasp-report.md`](reference/owasp-report.md): attack vectors, mitigations, and worked examples for every Top 10:2025, ASVS 5.0, LLM Top 10, and Agentic item. About 1100 lines: jump to the section you need.

Security Review Workflow

Copy this checklist into your response and tick it off as you go:

Security Review Progress:
- [ ] Step 1: Map entry points and trust boundaries
- [ ] Step 2: Load the references this code needs
- [ ] Step 3: Sweep for candidate issues
- [ ] Step 4: Triage every candidate
- [ ] Step 5: Report findings

**Step 1: Map entry points and trust boundaries.** List where attacker-controlled data enters: routes and handlers, headers and cookies, uploads, webhooks, queue consumers, CLI arguments, third-party API responses, and anything an LLM reads or returns. Note where authentication and authorization are enforced; it is often centralized in middleware rather than per route.

**Step 2: Load the references this code needs.** The language section of `languages.md`; `config-and-supply-chain.md` if config, IaC, dependencies, or CI changed; the LLM and Agentic sections of `owasp-report.md` if the code calls a model or runs an agent.

**Step 3: Sweep for candidate issues.** Walk `review-checklist.md` for the categories the code touches. For each candidate, trace the path from an entry point in step 1 to the sink.

**Step 4: Triage every candidate** with the rubric in "Before Reporting a Finding" below. Drop candidates that fail it, or downgrade them to defense-in-depth. If a candidate's reachability is unclear, go back to step 1 for that input before deciding.

**Step 5: Report findings** in the format below, highest severity first.

Before Reporting a Finding

A pattern match is not a vulnerability. The most common failure mode in automated security review is reporting unreachable or already-mitigated code, which buries the real findings. Confirm all four before reporting:

1. **Is the input actually attacker-controlled?** Trace it back to a real entry point: a request parameter, header, cookie, uploaded file, webhook, queue message, or third-party API response. A value that only ever comes from a constant, an enum, or trusted internal config is not an injection source. 2. **Is the sink reachable with that input?** Check whether validation, an allowlist, an ORM, or a framework-level control already sits between them. Look for auth middleware (`middleware.ts`, `proxy.ts`, Express/Django/Rails middleware, a base controller, decorators) before flagging a route as missing authorization. Enforcement is often centralized rather than per-route. 3. **What is the blast radius?** Who can trigger it, what do they get, and does it cross a trust boundary? An SSRF reaching cloud metadata differs from one reaching localhost only. 4. **Can the attacker perform every step?** Each step of the exploit must be possible from the attacker's position. A symlink race needs a way to create symlinks on the server; a header attack needs a client that can set that header. If a step needs a capability the code doesn't show the attacker having, the finding is "Needs verification", not High.

Report severity by exploitability, not by pattern. State the concrete path (*this input reaches this sink*) and say so explicitly when a finding is theoretical or defense-in-depth rather than directly exploitable. If reachability can't be determined from the code available, say that instead of asserting either way.

Reporting Format

One block per finding, highest severity first:

[SEVERITY] Title (CWE-###, OWASP A##:2025, LLM## Risk Name, ASI## Risk Name)
Location:   path/to/file.ext:LINE
Path:       <entry point> -> <intermediate hops> -> <sink>
Impact:     who can trigger it, what they get, which trust boundary it crosses
Fix:        the concrete change, with a code snippet when it isn't obvious
Confidence: Confirmed | Likely | Needs verification (say what you couldn't see)

Write every LLM and ASI ID with its risk name, e.g. "LLM03 Excessive Agency". A bare LLM ID is ambiguous: the 2025 and 2026 editions use the same numbers for different risks.

| Severity | Meaning | |---|---| | Critical | Unauthenticated remote code execution, auth bypass, or mass data exposure | | High | Authenticated exploitation crossin