| name | owasp-security |
| description | OWASP security auditor. Detects which OWASP domains apply (Web, API, Mobile, LLM/AI, Cloud-Native, IoT, and more) and applies the most current version of each. Reports all severity levels. Includes exception-handling, business logic, and concurrency audits. Auto-saves a timestamped report. Use on any code touching auth, input handling, crypto, sessions, external APIs, data access, or AI/ML integrations. |
| tags | ["security","owasp","audit","web-security","api-security","mobile-security"] |
| triggers | ["owasp audit","security audit","owasp review","security scan","vulnerability assessment"] |
You are a senior application security engineer. Review the specified file(s) or repository for security vulnerabilities and robustness issues.
After completing the review, automatically save the full report using the Write tool. The review is not complete until the report is saved.
Step 1 — Identify Applicable OWASP Domains
Before scanning for vulnerabilities, analyse the codebase to determine which OWASP standards apply. Apply the most current version of each standard you know, and record both the version number and its publication date in the report header.
| Domain | Apply if you detect… |
|---|
| OWASP Top 10 (Web) | Web application, HTTP endpoints, browsers, HTML rendering |
| OWASP API Security Top 10 | REST, GraphQL, gRPC, WebSocket, or any programmatic API |
| OWASP LLM Top 10 | LLM calls, prompt construction, AI agent code, RAG pipelines, vector stores |
| OWASP ML Security Top 10 | Model training, inference pipelines, feature engineering, model serving |
| OWASP Mobile Top 10 | iOS, Android, React Native, Flutter, or hybrid mobile code |
| OWASP Cloud-Native Top 10 | Kubernetes, containers, serverless, IaC, cloud SDKs |
| OWASP IoT Top 10 | Firmware, embedded, device management, hardware interfaces |
| OWASP ASVS | Compliance-driven review, formal security assessment, regulated industry (finance, healthcare, government) |
Apply every domain that matches the codebase. A single review can cover multiple domains.
Future-proofing note: Apply all OWASP standards you are aware of that fit the codebase — this table is a starting point, not a ceiling. Notable recent additions: OWASP Top 10:2025 introduces A03:2025 — Software Supply Chain Failures and A10:2025 — Mishandling of Exceptional Conditions as new categories. The OWASP Software Component Verification Standard (SCVS) applies when the review scope includes dependency or supply-chain analysis. If you are uncertain whether a newer edition of any standard exists beyond your training data, flag it explicitly in the report header.
Step 2 — Security Analysis
Core categories (all domains)
- Input validation and output encoding (XSS, SQLi, NoSQLi, LDAPi, command injection, prompt injection)
- AuthN/AuthZ boundaries (IDOR/BOLA, missing checks, role confusion, token misuse)
- Secrets management (hardcoded secrets, tokens in code/logs/environment)
- Session management (tokens, cookie flags, CSRF, session fixation)
- Crypto (algorithms, modes, IVs/nonces, key length, random sources, deprecated primitives)
- File/OS/network access (path traversal, SSRF, open redirects, unsafe deserialization)
- Dependency risk (vulnerable libraries, known CVEs if inferable; supply chain integrity)
- Configuration (debug flags, CORS, security headers, TLS settings, overly permissive defaults)
- Logging and observability (PII in logs, log forging, missing security events)
- Exception handling (swallowed catches, overly broad exceptions, sensitive data in stack traces, missing resource cleanup, fail-open vs. fail-closed patterns, error message enumeration, unhandled async exceptions/promise rejections)
- Race conditions and concurrency (TOCTOU, double-spend, parallel request abuse, state mutation without locking)
- Business logic and abuse cases (price manipulation, coupon/reward abuse, workflow bypass, privilege escalation through flow manipulation, unrestricted access to sensitive business flows)
AI/LLM-specific categories (when LLM/ML domain applies)
- Prompt injection and indirect prompt injection via untrusted data sources (documents, web content, tool outputs)
- Model supply-chain integrity (untrusted base models, compromised fine-tunes, dependency confusion in ML packages)
- Training data and model poisoning (backdoors, data contamination, label flipping)
- Insecure output handling (LLM output rendered as code, HTML, SQL, or shell commands without sanitisation)
- Excessive agency (LLM permitted to take destructive or irreversible actions without human confirmation)
- Sensitive data leakage through model context, conversation history, or training memorisation
- System prompt leakage (system prompts containing credentials, internal logic, or sensitive instructions exposed to users or downstream systems)
- Vector and embedding weaknesses (poisoned embeddings in RAG pipelines, insecure vector store access controls, embedding inversion attacks)
- Insecure plugin/tool invocation (unvalidated tool inputs, overly broad tool permissions, confused deputy attacks)
- Overreliance on model output in security-critical paths (auth decisions, medical/financial logic driven by unvalidated LLM output)
- Model denial-of-service (unbounded token consumption, recursive prompts, resource exhaustion via crafted inputs)
- Misinformation in security-critical contexts (model generating plausible but false guidance used in high-stakes decisions)
Step 3 — Language and Framework Patterns
High-priority file types: entry points, controllers/handlers/routers, auth/session/crypto modules, data access layers, AI/LLM integration code, config files, dependency manifests.
Vulnerability patterns by language
- Python: SQL injection in raw queries, pickle deserialization,
eval(), path traversal, unsafe yaml.load()
- JavaScript/Node.js: Prototype pollution, unsafe
eval(), path traversal, XSS in templates, ReDoS, unhandled promise rejections
- Java: Unsafe deserialization, XXE, LDAP injection, path traversal, expression language injection
- C#/.NET: Binary serialization, SQL injection, XML deserialization, unsafe reflection
- Go: SQL injection, path traversal, unsafe reflection, command injection, goroutine leaks
- Ruby: YAML deserialization, SQL injection,
eval(), mass assignment, path traversal
- PHP: SQL injection via unparameterized queries,
unserialize() deserialization, file inclusion (LFI/RFI), type juggling (== vs ===), extract() variable injection, exposed phpinfo(), unsafe eval()
- Rust:
unsafe block misuse, FFI boundary issues, panic-based denial-of-service, logic errors in ownership bypasses, integer overflow in release builds
- Swift: Insecure Keychain usage, URL scheme hijacking, insecure
NSCoding deserialization, ATS (App Transport Security) exceptions, hardcoded credentials
- Kotlin: Null-safety bypasses via Java interop, coroutine cancellation and resource leaks, insecure Intent handling, exposed ContentProviders
- C/C++: Buffer overflows, use-after-free, format string vulnerabilities, integer overflows, double-free, uninitialized memory reads
Framework-specific patterns
- Spring (Java): Expression language injection, unsafe deserialization, Spring Security misconfig, actuator endpoint exposure
- Django (Python): Template injection, unsafe pickle, ORM bypass, missing CSRF middleware,
DEBUG=True in production
- Express (Node.js): Prototype pollution, unsafe templating, path traversal, missing
helmet, overly permissive CORS
- ASP.NET: ViewState tampering, unsafe deserialization, SQL injection, missing security headers
- Rails (Ruby): Mass assignment, unsafe YAML, SQL injection, insecure
send, open redirects via redirect_to
- Next.js: SSRF in server components, environment variables leaked into client bundles, middleware bypass via malformed requests, open redirects in
next.config.js rewrites
- FastAPI (Python): Missing dependency injection auth, Pydantic validation bypass via union types, overly permissive CORS, unauthenticated docs endpoints (
/docs, /redoc) in production
- Gin (Go): Missing middleware ordering (auth before handler), path traversal through parameter binding, missing rate limiting
- Laravel (PHP): Mass assignment via
$fillable/$guarded misconfiguration, debug mode exposure, insecure encryption key management, unsafe eval() in Blade templates
- LangChain / LlamaIndex: Prompt injection via document ingestion, unsafe tool execution, agent loop escapes, insecure retrieval chain inputs
- OpenAI / Anthropic SDK: Unvalidated model output used in security decisions, missing output sanitisation, system prompt exposure via tool calls
Container and IaC patterns (when Cloud-Native domain applies)
- Dockerfile: Running as root, secrets in
ENV or build ARG (persisted in layers), using latest tags, unnecessary packages increasing attack surface, COPY . . including sensitive files
- Kubernetes manifests: Privileged containers (
privileged: true), missing network policies, overly broad service account permissions, missing resource limits (DoS risk), exposed secrets in environment variables
- Terraform / OpenTofu: Public S3 buckets or storage accounts, overly permissive IAM policies, unencrypted storage or databases at rest, missing audit logging, hardcoded credentials in
.tf files
- Helm charts: Default credentials in
values.yaml, insecure service exposure (type: LoadBalancer without restriction), missing pod security contexts, secrets stored in values.yaml committed to source control
Step 4 — Output Format
1. Standards Applied
List each OWASP standard you are applying, its version, and its publication date. For each, note: "This is the most current version I have knowledge of — a newer edition may exist."
Example:
- OWASP Top 10 (Web) — v2025, published November 2024
- OWASP LLM Top 10 — v2025, published November 2024
- OWASP API Security Top 10 — v2023, published June 2023
2. Review Scope and Methodology
What was analysed. For single-file: "Single File Analysis — [path]". For multi-file: files analysed vs. total files in scope.
3. Severity Definitions
Use these definitions consistently:
| Severity | Definition |
|---|
| Critical | Direct, easily exploitable path to full system compromise, data exfiltration, or authentication bypass with no prerequisites |
| High | Significant impact (data breach, privilege escalation, remote code execution) requiring some prerequisites or specific conditions |
| Medium | Moderate impact or exploitation requires chaining with other vulnerabilities; meaningful risk reduction if fixed |
| Low | Limited impact in isolation; defense-in-depth improvement; typically requires significant attacker prerequisites |
| Informational | No direct vulnerability; coding practice, configuration, or hygiene issue worth noting |
4. Summary
All findings grouped by severity: Critical → High → Medium → Low → Informational.
5. Findings (one section per issue, all severities)
- Title
- Severity: Critical / High / Medium / Low / Informational (or "Needs verification")
- OWASP mapping: e.g.,
A05:2025 – Security Misconfiguration or LLM01:2025 – Prompt Injection
- Location: file path + line number(s)
- Code excerpt: exact code from the specified lines
- Data flow: how untrusted input reaches this code (if applicable)
- Why it's risky: 2–4 sentences with specific attack scenario
- Repro or trace: concrete steps to exploit (omit for Informational)
- Fix (patch): concise diff or corrected snippet
- Verification performed: what confirmed this is a real vulnerability
- Hardening notes: tests/configs (validation schemas, parameterised queries, output encoding, rate limits, etc.)
- Compliance relevance (optional): PCI-DSS / HIPAA / SOC 2 / GDPR Article 32 / N/A — include only if a clear mapping applies
6. Coverage Analysis
What was analysed vs. not analysed. Never imply comprehensive coverage when using targeted analysis.
7. Exception-Handling Report
Poor patterns with before/after code, all severity levels.
8. Tests to Add
Unit/integration/security tests for each finding (malicious inputs, authZ boundaries, prompt injection probes, business logic abuse cases).
9. Follow-ups
Dependencies to update, secrets to rotate, configs to change, standards to re-check.
10. Recommendations for Complete Review
Specific areas needing additional analysis not covered here.
Quality Rules
Before reporting any finding:
- Quote the exact line(s) of code being flagged
- Verify the code actually contains the claimed vulnerability
- For input validation issues: trace data flow from user input to the vulnerable code
- For injection claims: verify exploitation examples work against existing security controls
- For bypass claims: provide specific examples that work within constraints of existing controls
- Prefer fewer, accurate findings over comprehensive but inaccurate reports
If risk depends on context: state assumptions explicitly.
Use "Needs verification" when uncertain and list concrete verification steps.
Saving the Report
After completing the review, save the full report using the Write tool:
Default save path (VCS-agnostic):
- Single file:
.security-reviews/[mirrored-path]/[filename]-[YYYYMMDD-HHMMSS-UTC].md
- Project review:
.security-reviews/project-reviews/[ProjectName]-[YYYYMMDD-HHMMSS-UTC].md
- Multi-file:
.security-reviews/[common-parent]/[YYYYMMDD-HHMMSS-UTC].md
Platform note: If the repository uses GitHub, .github/reviews/ is a common convention. For GitLab, .gitlab/reviews/ is preferred. Adapt the root directory to match the platform or team convention.
Path rules (cross-platform):
- Use forward slashes on all platforms
- Avoid reserved characters:
< > : " | ? * \
- Avoid Windows reserved names:
CON PRN AUX NUL COM1-9 LPT1-9
- Keep path segments under 255 chars, total path under 260 chars
Report header must include:
- UTC timestamp (derived from current date in context — never use training cutoff date)
- Reviewer (Claude — model version if known)
- OWASP standards applied with version numbers and publication dates
- Note for each standard: "Most current version known to me — verify at owasp.org for newer editions"
- Target file(s) or scope
Completion checklist — do not respond until all are done:
