Fuzz Testing: Finding Bugs with Random, Invalid Inputs

Why it exists

Developers test their code against expected, valid inputs. But attackers and real-world corruption don't follow the rules. Fuzzing was created to automate the discovery of bugs that only surface when a program receives malformed, unexpected, or malicious data.

The mental model

Think of a fuzzer as a tireless, malicious user who keeps trying to break your application by feeding it junk. But it's not just random junk. It's intelligently crafted junk, designed to look just enough like a valid file or network packet to get past the front door, then cause chaos inside the deeper logic.

How it works

A fuzzer takes a description of a program's expected input, like a file format or protocol, and generates a massive number of variations. These inputs are often "semi-valid"—they respect the basic structure but contain invalid values, incorrect lengths, or unexpected data in corner cases. The fuzzer then runs the program with each generated input, monitoring for exceptions like crashes, failed assertions, or memory leaks.

When to use it

Fuzzing is highly effective for any code that parses complex, structured data. This is crucial for: first, security testing, to find vulnerabilities like buffer overflows before attackers do; second, protocol handlers, to ensure network services are robust against malformed packets; and third, file format parsers, to test applications that open images, documents, or other complex files.

When not to use it

Fuzzing is not the right tool for testing business logic that isn't directly tied to input parsing, like verifying a financial calculation. It also struggles with programs that require complex state or user interaction before the input is processed, as it primarily focuses on the input-processing boundary.

One canonical example

A fuzzer for a JPEG image decoder would start with a valid image. It would then systematically corrupt it in small ways: changing the width and height values to be enormous or negative, altering data chunks, or providing an incorrect file length. The goal is to see if the decoder crashes or leaks memory when trying to process these broken images, which could indicate a exploitable security vulnerability.