Fuzz

Fuzz Input Generation

Generate intelligent, context-aware fuzz test inputs by analyzing input parsing code. Produces boundary values, type confusion inputs, encoding edge cases, format-specific attacks, and injection payloads tailored to the specific parser and data types in scope. Output is structured JSON test case sets ready for integration with test harnesses.

Supported Flags

Read ../../shared/schemas/flags.md for the full flag specification.

Workflow

Step 1: Identify Input Handlers

Locate input parsing and processing code in scope:

1. API endpoint handlers: Functions that read request body, query params, headers.
2. File parsers: Functions that parse uploaded files, config files, data imports.
3. CLI argument parsers: Argument parsing with argparse, commander, cobra, clap.
4. Message consumers: Functions processing messages from queues, WebSockets, SSE.
5. Deserialization points: JSON.parse, XML parsing, YAML loading, protobuf decoding.
6. Database query builders: Functions constructing queries from user input.

For each handler, identify:

• Expected input type (string, number, array, object, file).
• Validation rules (regex, schema, type checks, length limits).
• How the input is used downstream (SQL, shell, HTML, file path, URL, regex).

Step 2: Analyze Input Constraints

Read the code to understand what the parser expects and what it guards against:

1. Type expectations: What types does the code assume? Where are type coercions?
2. Length limits: Are there explicit length checks? What happens at max length?
3. Character restrictions: Are certain characters filtered or escaped? Which ones?
4. Format requirements: Does the input need to match a pattern (email, URL, date)?
5. Range constraints: Numeric bounds, enum values, allowed file extensions.
6. Nested structure: How deep can objects/arrays nest? Are there recursion limits?

Step 3: Generate Boundary Value Inputs

For each input field, generate boundary value test cases:

Step 4: Generate Type Confusion Inputs

Inputs designed to exploit type coercion and type assumption bugs:

Generate inputs that send the wrong type: string where number expected, array where string expected, object with toString override, deeply nested arrays, null where required, boolean where string expected, numeric string where number expected, and prototype/constructor pollution objects (__proto__, constructor.prototype).

Step 5: Generate Encoding Edge Cases

Inputs exploiting encoding and character set handling:

1. Unicode: Normalization forms (NFC, NFD, NFKC, NFKD), homoglyphs, right-to-left override, zero-width characters.
2. URL encoding: Double encoding (%2527), mixed encoding, overlong UTF-8.
3. HTML entities: Named (&), numeric (&), hex (&), surrogate pairs.
4. Null bytes: Mid-string null bytes for truncation attacks.
5. Line endings: \r\n, \r, \n, \x0b, \x0c, \x85, \u2028, \u2029.
6. Case mapping: Turkish locale I/i dotless variants, German ß/SS.

Step 6: Generate Context-Aware Injection Payloads

Based on how the input is used downstream (identified in Step 1), generate targeted payloads:

Step 7: Generate Format-Specific Attacks

At --depth deep and above, generate inputs targeting specific file/data formats:

1. JSON: Duplicate keys (parser-dependent behavior), comments, trailing commas, BOM prefix.
2. XML: Billion laughs, quadratic blowup, external entities, CDATA abuse.
3. YAML: Anchor bombs, merge keys, tag deserialization (!!python/object).
4. CSV: Formula injection (=CMD()), field separator in values, newlines in quoted fields.
5. JWT: Algorithm none, key confusion (RS256/HS256), expired but valid signature.
6. GraphQL: Deep nesting, alias flooding, batch query abuse, introspection.
7. Multipart: Boundary manipulation, filename traversal, content-type mismatch.

Step 8: Output Test Case Sets

Organize all generated inputs into structured JSON test case sets:

{
  "target": {
    "file": "src/api/users.ts",
    "function": "createUser",
    "input_field": "email",
    "expected_type": "string",
    "downstream_use": ["sql_query", "html_email"]
  },
  "generated_at": "2026-02-14T10:30:00Z",
  "total_cases": 85,
  "test_cases": [
    {
      "id": "FUZZ-001",
      "category": "boundary",
      "label": "empty_string",
      "input": "",
      "expected_behavior": "validation_error",
      "targets_cwe": "CWE-20"
    },
    {
      "id": "FUZZ-002",
      "category": "injection_sql",
      "label": "union_select",
      "input": "test@test.com' UNION SELECT * FROM users--",
      "expected_behavior": "parameterized_query_prevents_injection",
      "targets_cwe": "CWE-89"
    }
  ]
}

Write test case files to .appsec/fuzz/ organized by target.

Output Format

Fuzz inputs are not findings themselves but may reference CWEs they target.

Finding ID prefix: FUZZ (e.g., FUZZ-001) for test case identification.

• metadata.tool: "fuzz"

If fuzz testing reveals an actual vulnerability (input causes unexpected behavior), emit a finding using ../../shared/schemas/findings.md.

Pragmatism Notes

• Generate inputs relevant to the actual technology. Do not generate SQL injection payloads for code that never touches a database.
• Respect the --depth flag. Quick depth should produce 10-20 inputs. Expert depth can produce hundreds.
• Label each input clearly so testers understand what it targets and what behavior to expect.
• Mark intentionally dangerous inputs (e.g., billion laughs XML) with a warning about resource consumption.
• These are test inputs, not exploit code. Frame output as defensive testing material.
• If the code already has strong validation visible in the source, generate inputs that specifically test the validation boundaries.
• Include both inputs that should be rejected (malicious) and inputs that should be accepted (edge case valid) to test for false positives in validation.