Fuzzing Techniques for JSON Parser Security Testing

Start with the Highest-Yield Approach

If you are fuzzing a JSON parser today, the strongest default is coverage-guided, in-process fuzzing with a deterministic harness, memory/undefined-behavior sanitizers for native code, and a small but intentional seed corpus. That combination usually finds crash bugs, depth-limit failures, and parser inconsistencies much faster than pure random input generation.

The reason JSON is worth targeted security testing is that parsers often sit directly on trust boundaries: API gateways, mobile apps, browser code, SDKs, log ingesters, and config loaders. A bug does not need to be remote code execution to matter. Timeouts, stack exhaustion, memory blowups, or inconsistent handling of duplicate keys can all become real security issues once untrusted input reaches production.

For most teams, the practical goal is simple: make sure malformed or extreme JSON is rejected safely, deterministically, and within explicit resource limits.

JSON Behaviors That Deserve Focused Fuzzing

JSON looks small, but the edge cases that matter in parser security are concentrated in a few places. RFC 8259 says object member names should be unique, and it also warns that receiver behavior becomes unpredictable when they are not. That alone makes duplicate-key handling worth testing explicitly.

• Duplicate keys: Does the parser reject them, keep the first value, keep the last value, or behave differently across APIs?
• Unicode and escaping: Invalid UTF-8, unpaired surrogates, embedded nulls, and tricky escape sequences often expose boundary bugs.
• Number parsing: Leading zeros, very large integers, huge exponents, negative zero, and precision loss can all trigger divergent behavior.
• Trailing bytes and partial parses: Some parsers accept a valid root value and ignore junk that follows unless you test for it.
• Depth and size limits: Deep nesting, giant strings, and enormous arrays are common denial of service probes.
• Extension modes: If the library optionally accepts comments, trailing commas, `NaN`, or `Infinity`, fuzz strict and permissive modes separately.
• Streaming boundaries: Incremental parsers should also be tested with tokens split across awkward chunk boundaries.

These are the inputs most likely to reveal both correctness bugs and exploitable resource handling issues.

Fuzzing Techniques That Find Real Parser Bugs

The best campaigns usually combine several techniques instead of relying on one generator.

1. Mutation Fuzzing

Start with valid JSON samples and mutate them. Coverage guidance helps the fuzzer keep inputs that reach new states, while a JSON token dictionary helps it stay near interesting syntax. Mutation fuzzing is fast to set up and usually the best baseline.

2. Grammar-Aware or Structure-Aware Fuzzing

When random mutations die in the lexer too early, move up a level. Grammar-aware fuzzers generate valid or almost-valid JSON trees on purpose, so they spend more time in semantic code paths such as numeric conversion, UTF-8 validation, duplicate-name handling, and recursion limits.

3. Differential Fuzzing

Feed the same input to two parsers, or to the same parser in strict and permissive modes, then compare the outcomes. Differential fuzzing is especially good at finding non-crashing bugs such as silent truncation, number mismatches, or inconsistent handling of invalid Unicode and duplicate keys.

4. Resource-Focused Fuzzing

Some of the most valuable findings are not memory corruption at all. Run campaigns that deliberately stress recursion depth, total tokens, input size, and chunk fragmentation so you can catch stack overflow risks, allocator abuse, and algorithmic complexity problems before attackers do.

A Practical JSON Fuzzing Workflow

1. Choose the exact parser surface. Test every meaningful entry point: whole-buffer parse, DOM build, streaming/SAX parse, parse-from-bytes, and any permissive compatibility mode.
2. Build a deterministic harness. Every input should run fast, avoid network and filesystem dependencies, and reset global state between iterations. A flaky harness wastes fuzzing time.
3. Turn on sanitizers for native code. AddressSanitizer and UndefinedBehaviorSanitizer are a strong default because they convert silent memory corruption and undefined behavior into actionable crashes.
4. Seed with a small, high-quality corpus. Include empty structures, nested objects, escaped strings, large numbers, invalid Unicode samples, and known-bad cases such as trailing garbage or duplicate keys.
5. Add a JSON dictionary. Tokens such as {, }, [, ], :, ,, "true", "false", "null", and "\\u" help many fuzzers stay syntactically productive.
6. Set explicit limits. Cap bytes, nesting depth, token count, and per-input time. Security bugs often appear as missing or inconsistent limits rather than parser crashes.
7. Keep minimized reproducers. Every crash, timeout, or semantic mismatch should become a permanent regression test after triage.
8. Run short fuzz jobs in CI and longer jobs continuously. For open-source parsers, services such as OSS-Fuzz or lightweight PR checks are worth using because they keep exercising the corpus after the initial bug-finding burst.

extern "C" int LLVMFuzzerTestOneInput(const uint8_t* data, size_t size) {
  ParserOptions opts;
  opts.max_depth = 256;
  opts.max_input_bytes = 1 << 20;

  try {
    parse_json_bytes(data, size, opts);
  } catch (const ParseError&) {
    // Parse failures are expected. Crashes, sanitizer hits, and hangs are not.
  }

  return 0;
}

High-Value Corpus Ideas

A useful seed corpus is small, varied, and deliberately hostile.

• Duplicate keys: {"role":"user","role":"admin"}
• Trailing data: {"a":1}garbage
• Huge exponents and integer boundaries: 1e1000000, 18446744073709551616, -0, 00
• Unicode edge cases: "\\uD834\\uDD1E" versus "\\uD800"
• Deep nesting: thousands of repeated arrays or objects until the parser hits its configured maximum depth
• Large repeated strings: long escaped strings, long runs of backslashes, and embedded null bytes
• Permissive-mode probes: comments, trailing commas, NaN, and Infinity if the library has options for them
• Streaming cases: split a multibyte UTF-8 sequence, escape sequence, or number token across chunk boundaries

Keep the corpus understandable. When a sample no longer covers unique behavior, minimize or delete it so the fuzzer spends its time on inputs that still expand coverage.

Interpreting Findings Without Wasting Time

• Crash or sanitizer hit: Treat this as a high-priority parser bug until proven otherwise, especially in native code.
• Timeout or hang: Usually points to algorithmic complexity, recursion problems, or missing bounds checks.
• Out-of-memory event: Often means size or nesting controls are missing, inconsistently applied, or bypassed on one code path.
• Differential mismatch: Verify whether the divergence is an intentional policy choice or a silent correctness bug that could affect authorization, logging, or downstream validation.

A local formatter/validator is useful during triage. Pretty-printing minimized reproducers helps you separate valid-but-dangerous inputs from simply invalid JSON, and it makes parser-to-parser output comparison much easier.

Hardening Decisions After Fuzzing

Fuzzing is most valuable when it drives explicit parser policy, not just bug fixes.

• Decide how duplicate keys should behave and document that choice. Silent ambiguity is worse than strict rejection.
• Enforce limits on bytes, depth, token count, string length, and numeric range as close to the parser entry point as possible.
• Keep strict JSON parsing separate from convenience extensions so security-sensitive code paths do not accidentally inherit permissive behavior.
• Preserve the minimized corpus in version control and rerun it in CI before release.
• If untrusted JSON is business-critical, isolate parsing in a lower-privilege process or sandbox to reduce blast radius.