Security Fuzzing Input Generation Prompt

This prompt is designed for security engineers and DevSecOps teams who need to accelerate the creation of a targeted fuzzing corpus directly from source code analysis. The core job-to-be-done is transforming a static code artifact—a function, an endpoint handler, or a parser implementation—into a structured set of malicious and boundary-case inputs. You should use this prompt when you have access to the target source code, can clearly identify the input entry point, and understand the expected input format. It is a design-time input generator that feeds into your existing fuzzing pipeline, not a replacement for a full fuzzing harness or runtime instrumentation like libFuzzer or AFL++.

The ideal user is someone who can provide three critical pieces of context: the target source code, the specific function or endpoint that receives untrusted input, and a description of the input's expected structure. For example, if you are reviewing a new C++ parser for a binary protocol, you would supply the parser function, the struct definition it unmarshals data into, and a note that the input is a byte stream with a 4-byte length prefix. The model will then generate inputs targeting buffer overflows, integer overflows in the length field, and malformed type tags. This prompt is not suitable for black-box testing where you have no source code, for generating network-level packet captures without application logic context, or for compliance-mandated fuzzing that requires a specific coverage percentage from a certified tool.

Before using this prompt, ensure you have a clear vulnerability class taxonomy in mind, such as injection vectors, parser edge cases, or input validation boundary violations. The prompt works best when you constrain the output to a specific schema, such as a JSON array of objects containing the raw input, the vulnerability class, and an exploitability assessment. Avoid using this prompt as a one-shot security audit; the generated inputs must be executed in a real fuzzing harness with sanitizers and crash monitoring. The next step after generation is to feed the corpus into your fuzzer, triage any crashes, and use the results to refine the prompt's [CONSTRAINTS] for the next iteration.

This prompt template is designed to be pasted directly into your AI coding agent, security workflow, or DevSecOps pipeline. It instructs the model to analyze a given code snippet and produce a structured set of fuzzing inputs. The prompt is built to be self-contained, requiring only that you replace the square-bracket placeholders with your specific target code, language, and security constraints. The output is a categorized list of inputs, each mapped to a vulnerability class and an initial exploitability assessment, ready for use with fuzzing harnesses like AFL++, libFuzzer, or custom test rigs.

textCopy
You are a senior application security engineer specializing in fuzz testing. Your task is to analyze the provided source code and generate a comprehensive set of fuzzing inputs designed to uncover security vulnerabilities.

**Input Code:**
```[LANGUAGE]
[CODE_SNIPPET]

Analysis Constraints:

• Focus on input validation boundaries, parser logic, and external data deserialization points.
• Consider the following vulnerability classes: [VULNERABILITY_CLASSES], such as buffer overflow, format string, SQL injection, command injection, path traversal, and integer overflow.
• The target risk level for this assessment is [RISK_LEVEL].

Output Schema: Generate a JSON object with a single key "fuzzing_inputs" containing an array of objects. Each object must have the following keys:

• "input_string": The raw fuzzing payload as a string.
• "vulnerability_class": The primary vulnerability class this input targets.
• "target_code_location": A brief description of the code section the input is designed to test.
• "exploitability_assessment": One of "HIGH", "MEDIUM", "LOW", or "NEEDS_HUMAN_REVIEW".
• "rationale": A concise explanation of why this input is a meaningful test case.

Examples of Good Inputs: [EXAMPLES]

Output Format: Return ONLY the valid JSON object. Do not include any other text, markdown fences, or commentary.

To adapt this template, start by replacing [CODE_SNIPPET] with the specific function or module you are auditing. The [VULNERABILITY_CLASSES] placeholder should be tailored to the threat model of your application; for a web service, you might list 'SQL Injection, XSS, Command Injection', while for a native parser, 'Buffer Overflow, Integer Overflow, Use-After-Free' is more appropriate. The [EXAMPLES] placeholder is critical for in-context learning—provide 2-3 high-quality examples of inputs and their correct JSON analysis to guide the model toward the desired output structure and depth. After generating the inputs, always pipe the output through a JSON schema validator before feeding it to your fuzzing harness to prevent runtime errors from malformed AI output.

This prompt is designed to be called programmatically, not used in a one-off chat. The harness should feed the prompt a parsed function signature, relevant source code context, and a target vulnerability class, then collect the structured JSON output for downstream fuzzing engines. Because the output includes executable payloads and exploitability assessments, the harness must validate the schema, deduplicate inputs, and enforce severity-based routing before any generated input reaches a running system.

Wire the prompt into a CI workflow by triggering it on pull requests that touch input-handling code paths. Use a static analysis pass to extract candidate functions and their parameter types, then batch calls to the LLM with a concurrency limit appropriate for your rate tier. Each response must pass a JSON schema validator that checks for required fields (vulnerability_class, fuzzing_inputs, exploitability, rationale). Invalid responses should trigger a single retry with the same context and a stricter [CONSTRAINTS] block appended. Deduplicate generated inputs by hashing the payload field and discarding exact duplicates across batches. For high-risk vulnerability classes like RCE or deserialization, route the output to a manual review queue before any automated execution. Log every prompt version, model ID, input hash, and validation result for auditability.

Do not pipe generated fuzzing inputs directly into a production or customer-facing environment. Always execute fuzzing in an isolated sandbox with resource limits and crash monitoring. The harness should track which inputs caused crashes, hangs, or unexpected responses, and feed that telemetry back into future prompt runs as [EXAMPLES] of successful attack vectors. Avoid using this prompt on code paths that handle authentication tokens, session state, or cryptographic material unless the fuzzing environment is fully air-gapped and the generated inputs are treated as secrets.