ffuf when your wordlist is wrong
Filter tuning, recursion traps, and vhost fuzzing mistakes that waste hours on web engagements.
You ran ffuf with SecLists directory-list-2.3-medium.txt, got fourteen thousand lines of 200 responses, and spent the afternoon clicking PHPinfo pages on a CDN catch-all.
The ffuf cheat sheet documents the flags. It cannot tell you that the application's soft 404 returns HTTP 200 with 8,412 bytes every time. That part is on you.
Size filtering beats status code religion
Most tutorials stop at -fc 404. Production apps love custom error pages that return 200 or 302 with a stable body size.
Baseline the noise first:
curl -s -o /dev/null -w "%{http_code} %{size_download}\n" https://target.example/missing-path-xyz
Then fuzz with size exclusion:
ffuf -u https://target.example/FUZZ -w /usr/share/wordlists/dirb/common.txt \
-fs 8412 -mc 200,301,302 -t 40 -o ffuf-dirs.json
-fs (filter size) and -fw (filter words) are the difference between a useful run and a JSON file you will never open again. Word count filters help when the template wraps errors in the same HTML shell.
Recursion is not free
-recursion with a bloated wordlist on a rate-limited WAF is how you get banned before you reach /admin. I recurse only after a manual check on the first interesting hit, and I shrink the wordlist for depth:
ffuf -u https://target.example/FUZZ -w small-api-list.txt -recursion -recursion-depth 2 \
-fs 8412 -rate 30
If the target sits behind Cloudflare or Akamai, add -rate and accept slower output. Parallelism is not a personality trait.
Vhost fuzzing vs directory fuzzing
Mixing these up produces ghost hosts. Vhost mode needs the Host header slot:
ffuf -u https://10.0.0.5/ -H "Host: FUZZ.target.example" -w vhosts.txt -fs 0
Directory mode uses path insertion. Same tool, different failure mode. When DNS for *.target.example points to a sinkhole, vhost fuzzing against the origin IP is often the only way to find staging.
Compare with gobuster when you want a simpler dir-only workflow and less filter math. I keep both. ffuf wins when response shapes are weird.
Extensions and false positives on static sites
-e .php,.asp,.aspx,.bak can explode hit counts on servers that map unknown extensions to index.html. Filter again. Sometimes -ac (autocalibration) helps; sometimes it hides real hits because the calibration request was wrong.
Autocalibration is a starting point, not proof. Spot-check three random "misses" manually before you trust the filter chain.
Output you can actually use
-o file.json -of json plus -v for debugging one thread when results look wrong. Rename outputs by host and wordlist. ffuf.json in twelve folders is useless during report writing.
For authenticated areas, copy a valid session cookie into -b or -H "Cookie: ..." and fuzz behind login. The interesting paths rarely live on the anonymous surface.