Code Snippet Security Anti-Pattern Detection Prompt

This prompt is designed for security engineers and technical documentation reviewers who need to systematically audit code examples embedded in developer documentation, SDK READMEs, API quickstarts, and migration guides for security vulnerabilities. The job-to-be-done is not a general code review but a focused security anti-pattern scan: identifying hardcoded credentials, missing input validation, insecure default configurations, exposed secrets, and outdated cryptographic practices that could be copy-pasted by downstream developers into production systems. The ideal user has security domain knowledge and can triage findings, but the prompt itself encodes the detection patterns so that a senior developer or technical writer can run the initial scan before escalating to a security specialist.

Use this prompt when you have a batch of code snippets extracted from documentation and need a structured, consistent security audit. Required context includes the full code snippet, the programming language or framework, and the documentation context (e.g., 'this is a quickstart example for an authentication endpoint'). The prompt works best with snippets between 5 and 200 lines; larger code blocks should be split into logical units. You must also supply a [RISK_LEVEL] threshold to control sensitivity—'low' for informational flags only, 'medium' for likely vulnerabilities, and 'high' for strict detection of even potential anti-patterns. The prompt expects a defined [OUTPUT_SCHEMA] that maps findings to severity, CWE references, line numbers, and remediation guidance.

Do not use this prompt as a replacement for static analysis security testing (SAST) tools on production codebases, dynamic application security testing (DAST), or manual penetration testing. It is not designed to find novel zero-day vulnerabilities, business logic flaws, or context-dependent authorization bypasses. The prompt is also inappropriate for auditing code that is intentionally insecure for demonstration purposes unless you explicitly set [CONSTRAINTS] to suppress false positives for educational examples. For documentation that includes redacted credentials or placeholder values, add a pre-processing step to mark those as intentional before running the audit, or the prompt will flag them as hardcoded secrets. Always route findings rated 'critical' or 'high' to a human security reviewer before publishing remediation guidance to documentation consumers.

The prompt below is designed to be copied directly into your AI harness, IDE, or evaluation pipeline. It uses square-bracket placeholders for all dynamic inputs so you can swap in code samples, documentation context, and output format requirements without rewriting the core instruction. The template enforces a structured security audit that flags hardcoded credentials, missing input validation, insecure defaults, exposed secrets, and outdated cryptographic practices in documented code examples.

textCopy
You are a security engineer auditing code snippets in developer documentation. Your task is to identify security anti-patterns that could lead to vulnerabilities if copied by users.

## Input

[CODE_SNIPPET]

## Context

[LANGUAGE]: The programming language of the snippet.
[FRAMEWORK]: The framework or library used, if any.
[DOC_PURPOSE]: What the documentation example is intended to demonstrate.
[SECURITY_POLICY]: Optional. Internal security standards or rules to check against.

## Audit Categories

For each category below, determine if the snippet contains an anti-pattern. Provide a finding only when an issue exists.

1. **Hardcoded Credentials**: API keys, passwords, tokens, secrets, or connection strings in plain text.
2. **Missing Input Validation**: User-supplied data used without sanitization, validation, or parameterization.
3. **Insecure Defaults**: Debug mode enabled, permissive CORS, disabled certificate verification, default admin credentials.
4. **Exposed Secrets in Logs or Output**: Credentials or sensitive data written to stdout, logs, or error messages.
5. **Outdated Cryptographic Practices**: MD5, SHA1, DES, RC4, weak key lengths, or deprecated cipher suites.
6. **Injection Vulnerabilities**: SQL, command, LDAP, XPath, or template injection via unsanitized input.
7. **Missing Authentication or Authorization Checks**: Endpoints or functions lacking access control.
8. **Insecure Data Storage**: Plaintext storage of sensitive data, missing encryption at rest.
9. **Dependency Risks**: Use of known-vulnerable library versions or unmaintained packages.
10. **Error Information Leakage**: Stack traces, system paths, or internal details exposed to users.

## Output Format

Return a JSON object with this exact schema:

{
  "snippet_id": "string or null if not provided",
  "language": "string",
  "framework": "string or null",
  "overall_risk": "none" | "low" | "medium" | "high" | "critical",
  "findings": [
    {
      "category": "string from audit categories above",
      "severity": "low" | "medium" | "high" | "critical",
      "line_numbers": "string describing location, e.g., 'lines 4-7'",
      "description": "string explaining the vulnerability",
      "exploit_scenario": "string describing how an attacker could exploit this",
      "remediation": "string with the secure alternative",
      "cwe_id": "string or null, e.g., 'CWE-798'"
    }
  ],
  "secure_rewrite": "string containing a corrected version of the snippet, or null if no changes needed"
}

## Constraints

- Only report findings that are actually present. Do not invent issues.
- If the snippet is a minimal example for illustration, note this in the finding description but still flag the risk.
- For each finding, provide a concrete, compilable remediation.
- If no issues are found, return an empty findings array and overall_risk of "none".
- Do not include commentary outside the JSON output.

[ADDITIONAL_CONSTRAINTS]

To adapt this template, replace each bracketed placeholder with your actual inputs. The [CODE_SNIPPET] accepts raw code as a string—escape quotes and newlines as needed for your JSON transport. The [SECURITY_POLICY] placeholder can reference internal standards like "OWASP Top 10 2021" or your organization's specific secure coding guidelines. The [ADDITIONAL_CONSTRAINTS] field lets you inject extra rules, such as ignoring certain categories for tutorial code or requiring specific CWE mappings. After adapting, run the prompt through your evaluation harness with known-vulnerable and known-clean snippets to calibrate detection accuracy before production use.

This prompt is designed to operate as a pre-publication gate in a documentation CI/CD pipeline, not as a one-off audit tool. The implementation harness should treat each code snippet as a discrete unit of work, passing it through the prompt with consistent [LANGUAGE], [FRAMEWORK], and [RISK_LEVEL] parameters derived from the document's metadata. The model's output must be parsed into a structured JSON object containing a findings array, a severity enum (CRITICAL, HIGH, MEDIUM, LOW, NONE), and a requires_human_review boolean. This structured output is the contract between the prompt and the rest of the pipeline—without it, automated gating decisions become brittle and error-prone.

Validation and retry logic is critical because the prompt operates in a high-stakes security context. After receiving the model response, the harness must validate that: (1) the output parses as valid JSON matching the expected schema, (2) every finding includes a snippet_line reference that maps to an actual line in the input code block, (3) severity is one of the allowed enum values, and (4) cwe_id fields, when present, correspond to real CWE entries. If validation fails, implement a single retry with the error message injected into [CONSTRAINTS] as a correction instruction. If the retry also fails, escalate the snippet to the human review queue rather than silently accepting a malformed response. Log every validation failure and retry attempt with the snippet ID, model, timestamp, and error details for observability.

Model selection and tool integration should favor models with strong code reasoning capabilities. For most documentation pipelines, a capable mid-tier model (such as Claude 3.5 Sonnet or GPT-4o) provides sufficient accuracy for anti-pattern detection without the latency and cost of frontier models. However, for [RISK_LEVEL] values of CRITICAL—such as authentication code, cryptographic operations, or payment handling—consider routing to a stronger model or requiring mandatory human review regardless of the model's confidence. The harness should integrate with existing static analysis tools (Semgrep, CodeQL, or language-specific linters) by using their findings as pre-filtering signals: snippets that pass static analysis with zero findings can skip the LLM review entirely, reducing cost and latency. Snippets flagged by static analysis should be enriched with the tool's findings in [CONTEXT] before being sent to the prompt, giving the model additional signals to work with.

Human review integration is non-negotiable for CRITICAL and HIGH severity findings. The harness should route these findings to a review queue (GitHub issues, Jira tickets, or a dedicated review UI) with the original snippet, the model's finding, the static analysis results, and a pre-populated remediation suggestion. For MEDIUM findings, consider a confidence threshold: if the model's self-reported confidence is below 0.85, escalate to human review; otherwise, auto-generate a documentation fix PR with the suggested remediation. LOW severity findings can be logged for periodic batch review. Never auto-merge security-related documentation changes without human approval when the finding involves credential handling, cryptography, authentication, or authorization logic. The harness should also track false positive rates by requiring reviewers to classify each escalated finding as CONFIRMED, FALSE_POSITIVE, or NEEDS_CLARIFICATION, feeding this data back into prompt refinement and model selection decisions over time.