Input Validation Test Gap Detection Prompt

This prompt is for developers and AppSec engineers who need to harden input surfaces before code reaches production. It analyzes input parsing, sanitization, and validation logic to find untested injection vectors, type confusion points, and encoding edge cases. Use it during code review or as a pre-merge CI check when a changeset touches any code that accepts external input: HTTP handlers, API endpoints, file parsers, message queue consumers, or CLI argument processing. The prompt expects a focused code diff or a single file containing input-handling logic, plus a summary of existing test coverage for that code.

The prompt is not a general-purpose security scanner and will not replace a full penetration test or SAST tool. It is a targeted assistant for finding specific, untested validation gaps that a human reviewer might miss. For it to work, you must provide the actual input-handling code—not just a description of it—and a truthful accounting of which paths are already tested. The prompt reasons about the code's control flow, type coercions, encoding transformations, and boundary conditions to propose missing tests with concrete malicious or malformed inputs. It will not flag architectural security flaws, business logic abuse, or vulnerabilities outside the provided code surface.

Avoid using this prompt on code that has no existing test suite, as the gap analysis becomes a generic vulnerability scan without the precision of coverage-aware reasoning. Do not use it as a substitute for human security review on authentication, authorization, or cryptographic code. The output is a prioritized list of missing validation tests, each mapped to a specific input-handling code path. Treat every finding as a test recommendation, not a confirmed exploit. For high-risk systems, always pair the prompt's output with a manual AppSec review and ensure that generated test cases are added to the project's automated test suite before closing the review.

This prompt template is designed to analyze input parsing, sanitization, and validation logic in code changes and identify missing test cases. It focuses on injection vectors, type confusion points, encoding edge cases, and boundary conditions that lack corresponding test coverage. Replace each square-bracket placeholder with your actual code, constraints, and output requirements before sending to the model. The template is structured to produce a prioritized gap report where every finding maps to a specific input-handling code path.

textCopy
You are an input validation security analyst. Analyze the following code for input validation logic and identify test gaps.

## CODE TO ANALYZE
[CODE_DIFF_OR_FUNCTION]

## EXISTING TEST COVERAGE
[EXISTING_TEST_CASES_OR_COVERAGE_REPORT]

## INPUT SURFACE CONTEXT
- Input source: [INPUT_SOURCE e.g., HTTP request body, CLI argument, file upload, API parameter]
- Data type expectations: [EXPECTED_TYPES]
- Encoding context: [ENCODING_CONTEXT e.g., UTF-8, URL-encoded, base64]
- Downstream consumers: [DOWNSTREAM_SYSTEMS e.g., SQL database, HTML renderer, OS command]

## ANALYSIS REQUIREMENTS
For each input-handling code path, identify:
1. What validation exists (type checks, range checks, format validation, sanitization, encoding checks)
2. What test coverage exists for that validation
3. What test gaps remain

Focus on these vulnerability classes:
- Injection vectors (SQL, command, path traversal, template injection)
- Type confusion (string-to-integer coercion, null-to-empty conversion, prototype pollution)
- Encoding edge cases (double encoding, null bytes, Unicode normalization, homoglyphs)
- Boundary violations (overflow, underflow, negative values, empty collections, max length)
- Deserialization risks (untrusted JSON, YAML, pickle, XML entity expansion)
- Canonicalization bypasses (path normalization, URL parsing differences)

## OUTPUT FORMAT
Return a JSON object with this structure:
{
  "analysis_summary": {
    "total_input_paths_identified": <number>,
    "paths_with_adequate_coverage": <number>,
    "paths_with_gaps": <number>,
    "critical_gaps": <number>
  },
  "gaps": [
    {
      "gap_id": "<unique identifier>",
      "severity": "critical|high|medium|low",
      "code_location": {
        "file": "<path>",
        "line_range": "<start-end>",
        "function_name": "<name>"
      },
      "input_path_description": "<what input reaches this code and how>",
      "validation_present": "<what validation exists, if any>",
      "validation_missing": "<what validation is absent>",
      "vulnerability_class": "<injection|type_confusion|encoding|boundary|deserialization|canonicalization>",
      "exploit_scenario": "<concrete example of malicious or malformed input>",
      "existing_test_coverage": "<what tests exist or 'none'>",
      "recommended_test": {
        "test_type": "<unit|integration|fuzz|property>",
        "test_description": "<what the test should verify>",
        "malicious_input_example": "<specific input value to test>",
        "expected_behavior": "<what correct handling looks like>",
        "test_framework_suggestion": "<pytest, jest, JUnit, etc.>"
      },
      "false_positive_risk": "low|medium|high",
      "false_positive_rationale": "<why this might be a false positive>"
    }
  ],
  "safe_paths": [
    {
      "code_location": {"file": "<path>", "line_range": "<start-end>"},
      "validation_strategy": "<why this path is adequately protected>",
      "existing_test_reference": "<which tests cover it>"
    }
  ]
}

## CONSTRAINTS
- Every gap must reference a specific code location with file path and line range
- Every gap must include a concrete malicious or malformed input example
- Do not flag paths that are already adequately tested
- Distinguish between missing validation and missing tests for existing validation
- Mark gaps as critical only if they involve injection vectors or unvalidated input reaching dangerous sinks
- Include false_positive_risk assessment for every gap

## EXAMPLES
<example>
Code: `user_id = request.args.get('id')` followed by `db.execute(f"SELECT * FROM users WHERE id = {user_id}")`
Existing tests: Test with valid integer ID only
Gap: No test for string injection input like "1; DROP TABLE users;--"
Severity: critical
Vulnerability class: injection
Recommended test: Send "1; DROP TABLE users;--" as id parameter, verify query parameterization or rejection
</example>

<example>
Code: `filename = os.path.basename(user_input)` followed by `open(os.path.join(UPLOAD_DIR, filename), 'r')`
Existing tests: Test with normal filenames
Gap: No test for path traversal attempt like "../../../etc/passwd"
Severity: critical
Vulnerability class: injection (path traversal)
Recommended test: Send "../../../etc/passwd" as user_input, verify basename strips traversal or path is rejected
</example>

## RISK LEVEL
[RISK_LEVEL: high|medium|low - determines depth of analysis and whether human review is required]

If RISK_LEVEL is high, flag any gap where input reaches authentication, authorization, database, filesystem, or command execution sinks as requiring immediate human review.

Adapt this template by replacing the square-bracket placeholders with your actual code context. The [CODE_DIFF_OR_FUNCTION] should contain the specific input-handling code under review—a single function, a diff hunk, or a complete module. The [EXISTING_TEST_CASES_OR_COVERAGE_REPORT] can be test file contents, a coverage report excerpt, or a description of existing test scenarios. The input surface context fields help the model understand the attack surface: an HTTP parameter has different risks than a CLI argument. The [RISK_LEVEL] placeholder controls analysis depth—set it to high for authentication, payment, or PII-handling code where missed validation gaps are unacceptable. The examples section demonstrates the expected granularity: concrete malicious inputs, specific code locations, and actionable test recommendations. Do not remove the examples section unless you provide your own domain-specific examples, as they calibrate the model's output quality.

Before using this prompt in production, validate that your code input is complete enough for meaningful analysis. A single line without surrounding context will produce unreliable results. For high-risk code paths, always route findings through human security review before acting on them. The output JSON schema is designed to be machine-readable for integration into CI/CD pipelines, but the exploit_scenario and recommended_test fields should be reviewed by a developer who understands the codebase context. Avoid using this prompt on code you do not have permission to analyze, and never submit production secrets or credentials in the code input.

This prompt is designed to run inside a code review automation harness, not as a standalone chat interaction. The typical integration point is a pull request webhook or a pre-merge CI job that extracts the diff, identifies files touching input parsing, sanitization, or validation logic, and invokes the model with the prompt template. The harness must supply the [CODE_DIFF] and [EXISTING_TEST_SUITE] placeholders from the actual repository state. For AppSec use cases, you may also supply [SECURITY_POLICY] as a structured document describing allowed input patterns, encoding rules, and sanitization requirements so the model can flag deviations from policy, not just generic best practices.

Validation and output contract. The model output must conform to a strict JSON schema before the harness accepts it. Each finding requires a code_path field that references a specific function, method, or input-handling block in the diff, a gap_type from a controlled enum (injection_vector, type_confusion, encoding_edge_case, boundary_unchecked, sanitization_bypass), a malicious_input_example that would exploit the gap, and a recommended_test describing the assertion. The harness should validate that every code_path maps to a line range present in the diff and that no finding is a duplicate of an existing test case. Reject outputs that contain findings without concrete code references or that use vague gap descriptions like "input validation could be improved."

Retry and escalation logic. If validation fails—missing fields, unresolvable code paths, or generic findings—the harness should construct a retry prompt that includes the validation errors and asks the model to repair the output. Limit retries to two attempts. If the output still fails validation, escalate the gap report to a human reviewer with a note that automated analysis was inconclusive. For high-risk surfaces such as authentication endpoints, payment processing, or file upload handlers, always require human approval before closing the review, even when the model output passes validation. Log every invocation, the validated output, and the review decision for auditability.

Model choice and context window. This task requires strong code reasoning and security knowledge. Use a model with a context window large enough to hold the full diff, the relevant test files, and the security policy. If the diff exceeds the context window, pre-filter to files matching input-handling patterns (e.g., files containing request., req.body, $_GET, parse_, sanitize_, validate_, decode_, read() calls on user-controlled streams). Do not truncate the diff mid-function. For very large changesets, split by module and run the prompt independently, then merge and deduplicate findings in the harness. The prompt is not a replacement for SAST tools or fuzzing; it complements them by identifying gaps in test coverage that those tools do not evaluate.