Fuzz Testing

What it is

Fuzz testing throws vast amounts of malformed, random or adversarially mutated input at a program and watches for crashes, hangs, panics and memory errors. Unlike property-based testing, the goal is not a stated invariant — it is simply does it survive?

A coverage-guided fuzzer keeps input that reaches new code paths and mutates it further, so it explores deeper over time. When it finds a crash it saves the exact input as a crash reproducer.

1
   seed corpus ──► mutate ──► run target
2
        ▲                        │
3
        │        new coverage?   │
4
        └──────── keep ──────────┤
5
                                 ▼
6
                        crash / hang / sanitizer
7
                                 │
8
                                 ▼
9
                     save reproducer + stack trace

Modern fuzzers pair with sanitizers — AddressSanitizer, MemorySanitizer, UndefinedBehaviorSanitizer — to catch silent memory misuse, not just segfaults.

When to use it / when to avoid it

Use it for

Parsers and decoders for untrusted input: JSON, images, protocols, archives
Memory-unsafe code (C/C++/Rust unsafe), where a crash may be exploitable
Security-sensitive surfaces: auth, crypto glue, deserialisation
Continuous fuzzing in CI (OSS-Fuzz style) once a target exists

Avoid it when

The input space is tiny and enumerable — table-driven tests cover it
There is no clear crash oracle and no sanitizer — nothing will be flagged
The code is pure and already exhaustively tested with properties
You expect it to prove correctness; fuzzing finds crashes, not wrong answers

Frameworks & tools

Tool	Ecosystem	Notes
libFuzzer	C/C++ (LLVM)	In-process, coverage-guided; part of LLVM
AFL++	C/C++	Instrumentation, forkserver; `afl-fuzz`
Atheris	Python	Coverage-guided fuzzing for CPython
Jazzer	Java/JVM	JVM fuzzing, integrates with JUnit 5
cargo-fuzz	Rust	libFuzzer front-end for Rust, needs nightly
go-fuzz / native fuzzing	Go	`go test -fuzz` built in since Go 1.18
OSS-Fuzz	Multi	Google’s continuous fuzzing service
ClusterFuzzLite	Multi	Run OSS-Fuzz in your own CI

Quick setup

1
# JS has no in-process coverage fuzzer; drive a native target
2
npm install -D jazzer.js
3
npx jazzer fuzz/parse_target.js -- -runs=100000

1
pip install atheris
2
python fuzz_parse.py -max_total_time=60

1
go test -fuzz=FuzzParse -fuzztime=60s ./parser

1
<dependency>
2
  <groupId>com.code-intelligence</groupId>
3
  <artifactId>jazzer-junit</artifactId>
4
  <version>0.22.1</version>
5
  <scope>test</scope>
6
</dependency>

1
# SharpFuzz drives AFL++/libFuzzer against .NET assemblies
2
dotnet tool install -g SharpFuzz.CommandLine
3
sharpfuzz MyApp.Parser.dll

Example

1
const { FuzzedDataProvider } = require('@jazzer.js/core');
2

3
module.exports.fuzz = function (data) {
4
  const provider = new FuzzedDataProvider(data);
5
  const input = provider.consumeRemainingAsString();
6
  try {
7
    parseConfig(input);
8
  } catch (e) {
9
    if (!(e instanceof ParseError)) throw e;
10
  }
11
};

1
import atheris
2
with atheris.instrument_imports():
3
    from parser import parse_config
4

5
def TestOneInput(data: bytes):
6
    try:
7
        parse_config(data.decode("utf-8", "ignore"))
8
    except ParseError:
9
        pass   # expected for bad input
10

11
atheris.Setup([], TestOneInput)
12
atheris.Fuzz()

1
func FuzzParse(f *testing.F) {
2
  f.Add([]byte("{\"port\":8080}"))
3
  f.Fuzz(func(t *testing.T, data []byte) {
4
    // must never panic, whatever the bytes are
5
    _, _ = ParseConfig(data)
6
  })
7
}

1
import com.code_intelligence.jazzer.api.FuzzedDataProvider;
2
import com.code_intelligence.jazzer.junit.FuzzTest;
3

4
class ParserFuzzTest {
5
  @FuzzTest
6
  void fuzzParse(FuzzedDataProvider data) {
7
    String input = data.consumeRemainingAsString();
8
    try {
9
      Parser.parse(input);
10
    } catch (ParseException expected) {
11
      // bad input is fine; a crash is not
12
    }
13
  }
14
}

1
using SharpFuzz;
2

3
public static class Program
4
{
5
    public static void Main(string[] args) => Fuzzer.Run(data =>
6
    {
7
        try { Parser.Parse(data); }
8
        catch (ParseException) { /* expected */ }
9
    });
10
}

Anti-patterns & best practices

Commit your corpus and reproducers. A crash input is a regression test; keep it so the fix never silently regresses.
Fuzz the target, not the wrapper. Instrument the deepest parser, and let the harness only marshal bytes.
Build with sanitizers. ASan/UBSan/TSan catch the memory and undefined-behaviour bugs that do not segfault on their own.
Bound time and memory. Set -timeout, -rss_limit_mb and a run budget so one pathological input does not hang CI.
Treat any crash as a security bug first. Even a parser panic can be a denial of service; triage before dismissing.
Run continuously, not once. Fuzzing rewards time; wire a short run into CI and a longer OSS-Fuzz job optionally.