OWASP Top 10 Vulnerability Detection Prompt Template

This prompt is designed for application security engineers and DevSecOps teams who need to scan source code for vulnerabilities aligned with the OWASP Top 10. It is not a replacement for a SAST tool or a penetration test. Use it when you need a fast, code-context-aware triage pass that produces structured findings with exploit scenarios and fix suggestions. The prompt assumes you have already extracted the relevant code snippets and can provide file path and language context. It works best as part of a CI/CD gating workflow or a security review harness where a human reviews and calibrates the output before it becomes a ticket.

The ideal user has access to source code, understands the OWASP Top 10 categories, and can provide the model with focused code snippets rather than entire repositories. You should supply the code block, the programming language, the file path, and any relevant framework or library context. The prompt is most effective when targeting specific vulnerability classes—SQL injection, broken authentication, sensitive data exposure, XML external entities (XXE), security misconfigurations, cross-site scripting (XSS), insecure deserialization, components with known vulnerabilities, and insufficient logging and monitoring. Do not use this prompt for runtime behavioral analysis, infrastructure penetration testing, or cryptographic algorithm design review; those require different methodologies and tooling.

Before integrating this prompt into a production workflow, you must establish a human review step. The model can produce false positives by flagging safe patterns that resemble vulnerable code, and it can miss context-dependent vulnerabilities that require understanding of deployment configuration or business logic. Calibrate severity scores against your organization's risk taxonomy, and maintain a feedback loop where triage decisions are logged and used to refine the prompt or add few-shot examples. The prompt is a force multiplier for security review, not an autonomous vulnerability scanner.

This prompt template is designed to be the core instruction set for an AI coding agent performing an OWASP Top 10 vulnerability detection scan on a provided code snippet. It is structured to enforce a strict output schema, a calibrated severity taxonomy, and evidence-backed reasoning, ensuring the output is machine-readable for downstream triage systems and human-readable for security engineers. The template is not a conversational chatbot prompt; it is a deterministic instruction set for a code review task.

textCopy
You are an application security engineer performing an OWASP Top 10 vulnerability assessment on the provided source code.

## Input
- **Source Code:**
```[LANGUAGE]
[CODE_SNIPPET]

• File Path: [FILE_PATH]
• Context: [CONTEXT]

Task

Analyze the source code for vulnerabilities that map to the OWASP Top 10 ([OWASP_VERSION]) categories. For each finding, you must provide a detailed explanation, a severity rating, and a concrete remediation suggestion.

Constraints

• [CONSTRAINTS]
• Only report a vulnerability if you can trace it to a specific line of code or a clear pattern in the snippet.
• If no vulnerabilities are found, return an empty findings array. Do not hallucinate issues.
• Prioritize high-confidence, exploitable findings over theoretical weaknesses.

Output Schema

Return your analysis as a single JSON object conforming to this structure: { "findings": [ { "owasp_category": "A01:2021 – Broken Access Control", "title": "Short, descriptive title", "severity": "CRITICAL | HIGH | MEDIUM | LOW | INFO", "cvss_vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "location": { "file_path": "[FILE_PATH]", "line_numbers": [42, 43] }, "description": "A detailed explanation of the vulnerability and its potential impact.", "exploit_scenario": "A step-by-step description of how an attacker could exploit this weakness.", "remediation": "Specific, actionable code changes or configuration updates to fix the issue.", "false_positive_risk": "LOW | MEDIUM | HIGH", "references": ["https://cwe.mitre.org/data/definitions/..."] } ], "summary": { "total_findings": 0, "risk_level": "NONE | LOW | MEDIUM | HIGH | CRITICAL", "risk_assessment": "A one-paragraph executive summary of the overall security posture of the code." } }

To adapt this template for your specific environment, replace the square-bracket placeholders with concrete values. For instance, [LANGUAGE] should be set to python or javascript to help the model interpret syntax correctly. The [CONTEXT] placeholder is critical for reducing false positives; fill it with relevant architectural notes, known sanitization layers, or the function's intended trust boundary. The [CONSTRAINTS] field allows you to inject organization-specific policies, such as ignoring certain test files or flagging any use of a banned library. After adapting the prompt, you must pair it with a validation harness that checks the output against the JSON schema before the findings enter your ticketing system.

Integrating this prompt into a production workflow requires more than a single API call. The prompt is designed to be one step in a multi-stage security review pipeline. The application layer is responsible for preparing the input context, enforcing output validation, managing model selection, and ensuring that findings are traceable and actionable. Treat the prompt as a stateless function that receives a controlled code snippet and returns a structured vulnerability report.

The implementation harness should enforce a strict contract around the prompt. Before calling the model, assemble the [CODE_SNIPPET] and [FILE_PATH] from a secure source, such as a specific git diff or a file fetched from a trusted repository. After receiving the model's response, validate the JSON output against a defined schema. A failed validation should trigger a retry with a more explicit error message, not a silent fallback. Log every request and response, including the model version, prompt template version, and validation status, to an append-only audit store. For high-risk codebases, route all findings with a severity of HIGH or CRITICAL to a human review queue before they are accepted into the system of record.

Model choice significantly impacts the quality and cost of this workflow. For initial triage, a fast, cost-effective model like Claude Haiku or GPT-4o-mini can be used to scan large volumes of code. Findings from this first pass can then be re-evaluated by a more capable model, such as Claude Opus or GPT-4o, to reduce false positives and add exploit scenario detail. This two-tier routing pattern balances coverage with precision. Avoid using the prompt with a general-purpose chat model that has not been tested for structured output reliability, as format drift in the JSON report will break downstream automation. The next step is to build a regression test suite using the evaluation criteria to measure the impact of prompt or model changes before they reach production.