API Gateway and WAF Evasion Test Prompt

This prompt is designed for security testers and AppSec engineers who need to systematically probe whether an API gateway or Web Application Firewall (WAF) can be bypassed. The core job-to-be-done is generating a diverse set of obfuscated attack payloads and protocol-level manipulation scenarios that test the detection logic, not just the signature database. The ideal user has a working knowledge of HTTP, understands the target's expected positive-security model, and has a safe, authorized testing environment. The required context includes the target endpoint, the expected normal request structure, and the specific security control being tested (e.g., SQLi detection, path traversal blocking).

You should use this prompt when you need to move beyond running a standard vulnerability scanner and want to create repeatable, evidence-based test cases for specific evasion techniques. This includes testing how the gateway handles URL encoding variations, Unicode normalization, HTTP parameter pollution, header injection, and content-type manipulation. It is not a replacement for a full penetration test or a generic 'fuzz the endpoint' instruction. The prompt's value is in its structured approach to generating payload variants and defining the expected 'block' vs. 'pass' behavior for each, creating a clear, auditable test oracle. A critical constraint is that this prompt must never be used against production systems without explicit authorization and a rollback plan.

Do not use this prompt if you lack a way to observe the backend application's response or the WAF's decision logs. The primary failure mode is a false negative—where a payload bypasses the gateway and reaches the backend, but you cannot confirm the evasion because you only see a generic 200 OK response from the gateway itself. Without backend logs or a canary endpoint, you are testing blindly. Before using this prompt, ensure your test harness can distinguish between a request blocked by the WAF (e.g., a 403 status code with a specific error page) and a request that was passed through but handled safely by the application. The next step is to prepare your target request template and define the specific evasion categories you want to investigate.

This prompt template is designed to generate a structured set of test cases that probe the resilience of an API Gateway and Web Application Firewall (WAF) against evasion techniques. It takes a target endpoint, a known malicious payload, and a set of evasion tactics as input. The model's job is to systematically apply these tactics to produce obfuscated payload variants, predict whether each variant should be blocked or passed by a correctly configured defense, and specify the exact detection criteria. Use this template when you need to move beyond running a standard vulnerability scanner and want to understand the specific encoding or protocol-level blind spots in your defensive stack.

textCopy
You are a senior application security engineer designing evasion test cases for a Web Application Firewall (WAF) and API Gateway.

Your task is to generate a detailed test plan based on the provided inputs. For each evasion technique, you will create one or more obfuscated payload variants of the [BASE_PAYLOAD]. You will then predict the expected behavior of a correctly configured WAF/API Gateway and define the pass/fail criteria for the test.

## INPUTS
- **Target Endpoint:** [TARGET_ENDPOINT]
- **HTTP Method:** [HTTP_METHOD]
- **Base Malicious Payload:** [BASE_PAYLOAD]
- **Attack Type:** [ATTACK_TYPE] (e.g., SQLi, XSS, Command Injection)
- **Evasion Techniques to Test:** [EVASION_TECHNIQUES_LIST]
- **Expected Normal Response (Block):** [BLOCK_INDICATOR] (e.g., HTTP 403, 406, custom error page body text)
- **Expected Normal Response (Pass):** [PASS_INDICATOR] (e.g., HTTP 200, 404, expected data returned)
- **Output Schema:** [OUTPUT_SCHEMA]
- **Constraints:** [CONSTRAINTS]

## INSTRUCTIONS
For each evasion technique in [EVASION_TECHNIQUES_LIST], perform the following steps:
1.  **Obfuscate:** Apply the technique to the [BASE_PAYLOAD] to create one or more variant payloads.
2.  **Predict:** Determine if a well-tuned WAF/API Gateway should block or pass the obfuscated variant. Explain your reasoning based on how the defense parses the request.
3.  **Define Detection:** Specify the exact indicator that will determine if the test passed or failed in a real-world test (e.g., HTTP status code, response body content, connection reset).

## OUTPUT FORMAT
Output your results as a JSON array of test case objects, strictly conforming to the provided [OUTPUT_SCHEMA]. Do not include any text outside the JSON structure.

## CONSTRAINTS
- [CONSTRAINTS]

To adapt this template, replace the square-bracket placeholders with concrete values for your specific test scenario. The [EVASION_TECHNIQUES_LIST] should be a detailed list of tactics, such as "URL-encoding a single quote," "double URL-encoding the payload," "using Unicode normalization (NFKD) on a slash," or "inserting an HTTP header with a mixed-case Content-Type." The [OUTPUT_SCHEMA] placeholder is critical for automation; provide a strict JSON schema that defines the expected fields for each test case, such as test_case_id, technique_applied, obfuscated_payload, expected_behavior (block/pass), reasoning, and detection_criteria. The [CONSTRAINTS] field is where you add crucial safety and scope rules, such as "Do not generate test cases for HTTP Parameter Pollution (HPP) on this specific endpoint" or "All generated payloads must be URL-safe."

Before executing any generated test case against a live environment, you must implement a validation harness that parses the model's JSON output and checks it against the provided [OUTPUT_SCHEMA]. A common failure mode is the model generating a valid-looking test case but with a payload that doesn't actually contain the obfuscated attack string, leading to a false negative in your security assessment. Your harness should include a pre-flight check that verifies the obfuscated_payload field is not identical to the [BASE_PAYLOAD] and contains the core malicious syntax in some form. For high-risk production testing, always route the generated test plan through a human review queue to confirm the safety and accuracy of the predicted block/pass behavior before any request is sent.

This prompt is designed to be called programmatically from a security testing pipeline, not used as a one-off chat interaction. The harness must supply a structured [TARGET_DEFINITION] containing the API endpoint, expected WAF/gateway technology, and the specific security control under test. Because the prompt generates active attack payloads, the harness must enforce a pre-flight safety check that confirms the target environment is a designated test/staging system and not a production endpoint. Implement this as a mandatory boolean flag (production_safety_confirmed: false) that blocks execution unless explicitly overridden with a justification log entry.

The recommended integration pattern is a three-stage pipeline: (1) Generation — call the LLM with the prompt template, target definition, and evasion technique list to produce a batch of obfuscated payload variants and expected block/pass behavior. (2) Validation — before any payload is sent, run a schema validator against the output to ensure every test case includes the required fields: payload, encoding_stack, expected_waf_behavior, and detection_indicators. Reject and re-prompt any test case missing the expected_waf_behavior field, as this is critical for downstream pass/fail evaluation. (3) Execution and Evidence Capture — send each payload through a proxy (such as Burp Suite, mitmproxy, or a custom requests-based harness) and capture the actual HTTP response status, headers, and body. Log the raw response alongside the expected behavior for later comparison. Never execute payloads without a proxy layer that records full request/response pairs; WAF logs alone are insufficient for diagnosing false negatives.

For model choice, prefer models with strong instruction-following and structured output capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent). Set temperature to 0.2–0.4 to balance payload diversity against format reliability. If the model produces duplicate payloads across a batch, increase temperature slightly or add a [CONSTRAINTS] clause requiring uniqueness. Implement a retry loop with a maximum of 3 attempts: if validation fails, feed the validation error message back into the prompt as additional context and request a corrected output. After 3 failures, log the batch for human review and halt execution for that target. This prevents the harness from silently dropping test cases that the model cannot format correctly.

The most dangerous failure mode is a false negative — the WAF passes a malicious payload that should have been blocked, and the test harness marks it as 'expected pass' due to a misconfigured expectation. Mitigate this by requiring a human review gate for any test case where the actual WAF behavior diverges from the expected behavior. Flag these cases in a review queue with the payload, encoding stack, expected vs. actual response, and a suggested reclassification. Additionally, implement a coverage check after each run: verify that every evasion technique listed in [EVASION_TECHNIQUES] produced at least one test case. If a technique (e.g., Unicode normalization bypass) generated zero payloads, re-prompt with that technique isolated and a higher temperature.

Finally, treat the prompt output as evidence artifacts for audit and regression. Store each generated test case with a unique ID, timestamp, model version, and the full prompt context. When the WAF or gateway is upgraded, re-run the same test cases to detect regressions in blocking behavior. Wire the harness into your CI/CD pipeline as a gated security check that runs after infrastructure changes but before production deployment. Avoid running this prompt against third-party APIs or endpoints you do not own — the generated payloads are active attack attempts, and unauthorized testing may violate terms of service or applicable laws.