Web Fuzzing, from ZAP to ffuf

What fuzzing actually is

Fuzzing means sending a large, structured set of inputs at a target and watching which responses stand out from the crowd.

In web testing the inputs come from a wordlist, and a single placeholder, the keyword FUZZ, marks exactly where each word gets dropped into the request. Move that placeholder and you change the whole question you are asking. Put it in the path and you discover hidden directories and files. Put it in a parameter value and you probe for injection. Put it in the Host header and you enumerate virtual hosts the DNS never advertised.

The work is not the sending, it is the reading. A fuzzer can fire tens of thousands of requests in seconds, so the skill is telling signal from noise: a status code, a response size, or a timing that differs from the baseline is the thing you investigate. On a real engagement you run this only against systems within your authorized scope, and never against anything you have not been given written permission to test.

ZAP's fuzzer, the established workbench

ZAP is the tool most people meet first, and it is worth knowing where it stands today. It is a full dynamic analysis suite (an intercepting proxy, a spider, and an active and passive scanner), and the Fuzzer is one module inside that suite.

The workbench workflow

ZAP's strength is that the fuzzer lives right next to the proxy, so capturing a real authenticated request and fuzzing one field of it is point and click.

1. Proxy your traffic. Route the browser through ZAP, or use ZAP's bundled browser, and exercise the target so the request lands in the History tab.
2. Open the fuzzer. Right click the request in the Sites or History tab and choose Attack, then Fuzz, to load that request into the Fuzzer dialog.
3. Mark the target. Highlight the exact value you want to replace, then add a payload source: a built in list, a file, or a generated set.
4. Attach processors. Optionally add Message Processors, which can read and rewrite each request, control the run, and feed results back into the interface.
5. Run and triage. Start the fuzzer and read the results table, sorting by status code and response size to spot the responses that break the pattern.

Its payload engine draws on the older OWASP JBroFuzz project and ships lists from FuzzDB, with a few FuzzDB files deliberately left out because antivirus scanners flag them. The limits are exactly what push people toward a modern tool: it is a Java desktop application, the fuzzer is built for interactive use rather than scripting, and it is heavier than you want for fast, repeatable, automatable content discovery.

ffuf, the command line standard

ffuf, short for Fuzz Faster U Fool, is the current community standard for web fuzzing.

It is a fast fuzzer written in Go, shipped as a single static binary, and it is built for the terminal, which is precisely what makes it scriptable and pipeline friendly in a way ZAP's fuzzer is not. The whole model rests on one idea: put the keyword FUZZ anywhere in the URL, a header, or the body, and ffuf swaps in each line of your wordlist.

# Kali, Debian, Ubuntu (preinstalled on Kali, Parrot, BlackArch)
sudo apt install ffuf

# macOS (Homebrew)
brew install ffuf

# From source, and the same command updates it (needs Go 1.16+)
go install github.com/ffuf/ffuf/v2@latest

Three attack modes

These mirror Burp Intruder, which makes them an easy bridge for anyone who has already seen Burp.

Matching and filtering: how you cut the noise

This is the part that makes ffuf usable rather than overwhelming. Matchers keep responses (-mc status, -ms size, -mw words, -ml lines, -mr regex) and filters discard them (-fc, -fs, -fw, -fl). The everyday pattern is to match everything, then filter out the baseline, for example -mc all -fs 4242 to drop the standard not-found response. In practice you almost always add -ac, auto-calibration, which learns that baseline for you. Without it, results are usually too noisy to read.

Command cheat sheet

Each block is copy and run ready. The FUZZ keyword is highlighted so you can see where the injection point moves for each kind of test. Swap webapp-edge01 for your authorized target.

# Hidden directories
ffuf -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt \
     -u http://webapp-edge01/FUZZ -ac -c

# Same run, but append extensions to every word
ffuf -w wordlist.txt -u http://webapp-edge01/FUZZ -e .php,.html,.txt,.bak -ac

ffuf -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt \
     -u http://webapp-edge01/ -H "Host: FUZZ.target.local" -fs 4242

# Find a hidden parameter name (assume invalid names return 4242 bytes)
ffuf -w paramnames.txt -u 'http://webapp-edge01/script.php?FUZZ=test' -fs 4242

# Fuzz the value of a known parameter (assume a wrong value returns 401)
ffuf -w values.txt -u 'http://webapp-edge01/script.php?id=FUZZ' -fc 401

# POST login fuzzing (quote the & so the shell does not split it)
ffuf -w passwords.txt -X POST \
     -d 'username=admin&password=FUZZ' \
     -u http://webapp-edge01/login.php -fc 401

# JSON body, e.g. an IDOR probe on a numeric id (set Content-Type yourself)
ffuf -w ids.txt -X PUT \
     -H 'Content-Type: application/json' \
     -d '{"uid":"FUZZ"}' \
     -u https://webapp-edge01/api/v1/users/1 -mc all -fc 400

# Capture a request in ZAP or DevTools, drop FUZZ into the saved file,
# and let ffuf replay it. Cleanest way to carry cookies and tokens.
ffuf --request req.txt --request-proto https -w wordlist.txt -ac -o results.json

# Send only the matched hits into ZAP for manual follow-up
ffuf -w wordlist.txt -u http://webapp-edge01/FUZZ \
     -replay-proxy http://127.0.0.1:8080 -ac

# Recursion, with a per-job time cap so you do not loop forever
ffuf -w wordlist.txt -u http://webapp-edge01/FUZZ \
     -recursion -recursion-depth 2 -maxtime-job 120 -ac

# Report-ready output. JSON feeds n8n or a reporting script; HTML is client friendly.
ffuf -w wordlist.txt -u http://webapp-edge01/FUZZ -of html -o report.html

Build your ffuf command

Pick the kind of test, fill in the target, and the command assembles below with the FUZZ keyword placed in the right spot. Adjust the matchers, filters, and output to match the situation, then copy the result.

ZAP fuzzer versus ffuf

Neither replaces the other outright. ZAP is a complete analysis platform whose fuzzer shines for surgical, proxy adjacent work. ffuf is the fast, scriptable discovery engine. The honest answer for most assessments is both.

Other tools worth knowing

ffuf did not appear in a vacuum, and it is not the only modern option. A quick map of the neighborhood:

Wordlists and a safe place to practice

A fuzzer is only as good as its wordlist. The standard source is SecLists, preinstalled on Kali under /usr/share/seclists. Common starting points: Discovery/Web-Content/raft-large-directories.txt for directories, Discovery/DNS/subdomains-top1million-5000.txt for subdomains and virtual hosts, and Discovery/Web-Content/burp-parameter-names.txt for parameters. Project specific lists, built from the words a target actually uses, often find more than any generic list.

References and further reading

• ffufgithub.com/ffuf/ffuf and the ffuf wiki
• practiceffuf.me, an intentionally fuzzable practice host
• zapZAP Fuzzer add-on documentation and the ZAP project
• owaspOWASP WSTG, Fuzzing appendix
• listsSecLists, the standard wordlist collection