Use when you need to perform authorized web fuzzing with ffuf through a safe, reviewable workflow that starts with baseline calibration, uses explicit matcher/filter logic, bounds runtime, and preserves reproducible output for handoff.
Use when you need to perform authorized web fuzzing with ffuf through a safe, reviewable workflow that starts with baseline calibration, uses explicit matcher/filter logic, bounds runtime, and preserves reproducible output for handoff.
reuses a captured request where headers, cookies, or method matter
filters obvious bad-request noise while preserving unusual behavior for review
For a worked end-to-end exercise with command selection and result interpretation, open examples/worked-example.md.
Best Practices
Do:
Start with a baseline before selecting matchers or filters.
Use one fuzz dimension at a time unless a multi-wordlist job is clearly required.
Prefer machine-readable output such as JSON for review and handoff.
Bound runtime with -rate, -timeout, and -maxtime.
Re-validate promising hits with curl or a browser before reporting them as findings.
Record the exact command and any assumptions about wildcard responses or redirects.
Use the smallest effective wordlist first, then expand only if justified.
Do not:
do unauthenticated or unauthorized scanning
run recursion by default on a broad target
assume 200 means success or 403 means uninteresting
rely on a single signal when the app clearly uses soft-404s or generic redirects
hand off screenshots alone when JSON output and the exact command are available
let auto-calibration hide target-specific behavior without spot-checking the results
Troubleshooting
Symptoms: Almost every payload returns a match.
Solution: Establish a real baseline first. Compare size, word count, line count, redirect behavior, and body shape. Then switch from broad matching to explicit filters such as response size or word count. If the application uses wildcard routing or a custom 404 page, status code alone is usually insufficient.
Symptoms: Valid findings disappear after enabling auto-calibration or shared filters.
Solution: Re-test with narrower scope and inspect whether the baseline differs by host, path, or redirect target. In vhost or multi-domain workflows, shared calibration can suppress legitimate variants. Prefer per-target review over blind trust in automatic suppression.
Symptoms: Recursion causes the scan to grow too large or too noisy.
Solution: Remove recursion and rerun the first pass. Only recurse into directories that clearly produce distinct responses and operational value. Also reduce rate, set -maxtime, and use a smaller wordlist before expanding again.
Symptoms: The target starts timing out or behaving inconsistently.
Solution: Lower concurrency or request rate, increase timeout carefully, and shorten the scan scope. Confirm with curl whether the application is unstable, rate-limited, or fronted by a control layer such as a WAF.
Symptoms: Vhost results look inconsistent or all resemble the default site.
Solution: Verify DNS resolution and Host-header behavior manually with curl. Check whether TLS, SNI, reverse proxy configuration, or a default vhost page is masking differences. Filter against the true default body only after that baseline is confirmed.
Additional Resources
references/domain-notes.md — open this for compact operator guidance on calibration, matcher/filter selection, recursion decisions, output strategy, and known ffuf caveats.
examples/worked-example.md — open this for a concrete start-to-finish directory discovery exercise with baseline analysis and result triage.
Related Skills
No confirmed local related skills were provided in the source context.
