Fuzzing

What it means

Fuzzing throws large volumes of malformed or unexpected input at an application to see what falls over. Empty values, enormous values, wrong types, strange characters, structures nested far deeper than anyone planned for.

OWASP traces the technique back to 1989, and it is mechanical by design. The point is to try what nobody thought to try, which is the one job a machine does better than a person.

Why it matters

It finds crashes and parsing bugs, especially in code that handles files, documents, images or a custom format. Those crashes sometimes turn into something much worse in the hands of somebody patient. Google's OSS-Fuzz has found tens of thousands of bugs in open source projects this way.

For most businesses this is background vocabulary rather than a purchase. It matters if you write software that parses files or speaks an unusual protocol. It matters much less if you run a web application where the input is ordinary and the real risk is who may do what. Knowing which of those you are saves money.

How it shows up

Its limit is understanding. Fuzzing is poor at anything requiring knowledge of what the application is for. It will never conclude that a discount applies twice, or that this record belongs to another customer, because both are valid inputs producing valid responses.

A practical version for most teams is small. Send wrong types, missing fields, huge values and negative numbers to your own API endpoints. Then see which ones answer with an internal error and a stack trace attached. See input validation.