API Contract Fuzzing Test Case Generation Prompt

This prompt is for security and reliability engineers who need to generate boundary-testing payloads directly from an API specification. It takes an OpenAPI, JSON Schema, or similar contract document and produces a structured, prioritized suite of fuzzing test cases. Each test case targets a specific vulnerability class: type violations, constraint boundary values, unexpected fields, malformed inputs, and edge-case payloads. The output includes expected error responses per the spec, so the fuzzing suite can be wired into a CI pipeline or a dedicated API security testing harness.

Use this prompt when you have a machine-readable API contract and need to move from spec review to executable test generation without manually scripting every edge case. The prompt expects a complete specification as input—partial or undocumented APIs will produce incomplete test coverage and unreliable expected-error mappings. The generated test cases are designed for pre-production or staging environments where controlled fuzzing can validate that the API implementation correctly enforces its own contract. Each test case includes the attack vector, the specific payload, the expected HTTP status code, and the expected error response shape, making the output directly consumable by automated testing frameworks like schemathesis, Dredd, or custom fuzz harnesses.

Do not use this prompt for runtime DAST scanning, live production fuzzing without human review, or generating tests for APIs that lack a formal spec. The prompt does not perform active probing—it generates test cases from static contract analysis, so it cannot discover implementation-specific vulnerabilities that deviate from the documented contract. For production safety, always review generated payloads for destructive side effects before execution, especially for endpoints that modify data, trigger external processes, or consume billable resources. If your API handles regulated data or safety-critical operations, route all generated test cases through a human approval gate before any automated execution.

This prompt template generates a prioritized fuzzing test suite from an API specification. It instructs the model to produce test cases targeting type violations, constraint boundary values, unexpected fields, and malformed inputs. Each test case includes the payload, the expected error response per spec, and a priority level. Replace the square-bracket placeholders with your spec, configuration, and output requirements before wiring this into your CI pipeline or security testing harness.

textCopy
You are an API security testing engineer. Your task is to generate a comprehensive fuzzing test suite from the provided API specification.

## INPUT

### API Specification
[API_SPEC]

### Fuzzing Configuration
- Target endpoints: [TARGET_ENDPOINTS]
- Fuzzing depth: [FUZZING_DEPTH] (options: shallow, moderate, deep)
- Excluded test categories: [EXCLUDED_CATEGORIES]
- Max test cases per endpoint: [MAX_CASES_PER_ENDPOINT]

## OUTPUT SCHEMA

Return a JSON object with the following structure:
{
  "test_suite": [
    {
      "test_id": "string",
      "endpoint": "string",
      "method": "string",
      "category": "string (type_violation | boundary_value | unexpected_field | malformed_input | constraint_violation)",
      "priority": "string (critical | high | medium | low)",
      "payload": {},
      "expected_status": 0,
      "expected_error_schema": {},
      "spec_reference": "string (path or section in spec that defines the constraint being tested)",
      "rationale": "string (why this test case matters)"
    }
  ],
  "coverage_summary": {
    "total_cases": 0,
    "by_category": {},
    "by_priority": {},
    "untested_endpoints": []
  }
}

## CONSTRAINTS

1. Every test case must reference a specific constraint, schema definition, or parameter description from the provided API spec.
2. Priority assignment rules:
   - **critical**: Tests that could cause data corruption, authentication bypass, or service crashes.
   - **high**: Tests targeting required field violations, type mismatches on critical paths, or boundary values on size-limited inputs.
   - **medium**: Tests for optional field handling, unexpected additional fields, or format string edge cases.
   - **low**: Tests for cosmetic validation differences or non-functional edge cases.
3. For each endpoint, generate test cases across at least three categories unless excluded by configuration.
4. Expected error responses must match the error schema defined in the spec. If the spec does not define error schemas, note this in the rationale and propose a reasonable expected error based on HTTP semantics.
5. Do not generate test cases for excluded categories listed in [EXCLUDED_CATEGORIES].
6. If [FUZZING_DEPTH] is "shallow", focus only on required fields and type boundaries. If "moderate", include optional fields and constraint edges. If "deep", add malformed JSON, encoding attacks, and nested object edge cases.

## EXAMPLES

### Example Input (abbreviated OpenAPI snippet)
paths:
  /users:
    post:
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              required: [name, email]
              properties:
                name:
                  type: string
                  minLength: 1
                  maxLength: 100
                email:
                  type: string
                  format: email
                age:
                  type: integer
                  minimum: 0
                  maximum: 150

### Example Output
{
  "test_id": "fuzz-users-post-001",
  "endpoint": "/users",
  "method": "POST",
  "category": "boundary_value",
  "priority": "high",
  "payload": { "name": "A", "email": "test@example.com", "age": -1 },
  "expected_status": 400,
  "expected_error_schema": { "error": "validation_error", "details": [{ "field": "age", "constraint": "minimum" }] },
  "spec_reference": "#/paths/~1users/post/requestBody/content/application~1json/schema/properties/age/minimum",
  "rationale": "Tests lower boundary violation on age field. Negative age should be rejected per minimum: 0 constraint."
}

## INSTRUCTIONS

1. Parse the API specification to extract all endpoints, methods, parameters, request bodies, and their constraints.
2. For each target endpoint, generate test cases following the priority and category rules above.
3. Ensure every test case includes a spec_reference that traces back to the constraint being tested.
4. Output the complete test suite as valid JSON matching the output schema.
5. Include a coverage summary showing distribution across categories and priorities.

After pasting this template, replace [API_SPEC] with your OpenAPI, AsyncAPI, GraphQL schema, or gRPC proto definition. Set [TARGET_ENDPOINTS] to a list of specific paths or "all" for full coverage. Choose [FUZZING_DEPTH] based on your testing phase: use "shallow" for pre-commit CI checks, "moderate" for PR review gates, and "deep" for scheduled security scans. Set [EXCLUDED_CATEGORIES] to skip categories your system already handles elsewhere, such as ["malformed_input"] if a WAF already covers those cases. Cap [MAX_CASES_PER_ENDPOINT] to control token usage and test suite size—start with 10-15 per endpoint and increase if coverage gaps appear.

Before deploying this prompt to production, validate the output against your spec's actual error response format. The model may hallucinate error schemas if your spec does not define them explicitly. Add a post-processing step that maps generated expected_error_schema values to your actual error response envelope. For high-risk APIs handling PII or financial data, route critical and high priority test cases through human security review before adding them to your automated fuzzing suite. Store generated test suites with the spec version they were derived from to enable regression testing when the spec evolves.

This prompt is designed to be embedded in a security or reliability engineering pipeline, not run as a one-off chat interaction. The core integration pattern is: fetch the API specification artifact (OpenAPI, GraphQL schema, gRPC proto), extract the relevant contract surface, inject it into the prompt template along with fuzzing directives, and collect the structured output for downstream test execution. The harness must treat the LLM output as a test generation proposal—not as executable tests—and validate each generated case against the original spec before execution.

Pipeline wiring: Build a script or CI job that (1) reads the spec file from the repository or registry, (2) extracts endpoint definitions, parameter schemas, and constraint annotations, (3) constructs the prompt with [API_SPEC_SNIPPET], [FUZZING_STRATEGY], and [OUTPUT_SCHEMA] placeholders filled, (4) calls the model with response_format set to json_schema matching your expected test case array, and (5) runs a post-generation validator. The validator should check that every generated payload targets a real endpoint, uses fields present in the spec, and produces an expected status code within the spec's documented error range. Reject and regenerate any test case that references non-existent paths or invents parameters.

Model choice and retries: Use a model with strong structured output support (GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro) and set temperature between 0.3 and 0.6 to balance creativity in boundary exploration with schema adherence. Implement a retry loop: if the validator rejects more than 20% of generated cases, re-prompt with the validation errors appended as [PREVIOUS_FAILURES]. After two retries, flag the spec section for human review—it may contain ambiguous constraints that confuse the model. Logging: Record the spec version, prompt version, model, generated case count, validation pass rate, and any rejected cases. This audit trail is essential when a fuzzing test later finds a real vulnerability and the team needs to trace how that test case was generated.

Integration with test runners: The validated output should be transformed into your test framework's format (pytest parametrize, Jest test.each, k6 test data, Burp Suite intruder payloads, etc.). Do not send raw LLM output directly to a test runner. Add a transformation layer that maps each test_case object to an executable test function, injecting the payload, expected status, and any required auth headers. For high-risk production APIs, add a human approval gate before fuzzing tests execute against staging or production—review the generated payloads for destructive mutations (DELETE with unexpected IDs, state-changing POSTs with malformed bodies) that could corrupt test data.

What to avoid: Do not run this prompt against specs you don't own without explicit permission—generating fuzzing payloads for third-party APIs may violate terms of service. Do not skip the validation step; LLMs will occasionally hallucinate endpoints or parameters. Do not treat the generated test suite as comprehensive—it complements, not replaces, hand-crafted boundary tests and property-based testing frameworks. Start with read-only or non-destructive endpoints in staging, measure the false-positive rate (tests that fail because of spec misinterpretation, not real bugs), and tune the prompt's [CONSTRAINTS] section before expanding to mutating endpoints.