ffuf: A Fast Web Fuzzer for Finding What You Didn't Know Was There

You've got a target in front of you and a nagging feeling there's more to it than the homepage and a couple of obvious links. Maybe there's an admin panel hiding behind an unlinked path, a virtual host that only responds to the right Host header, or a parameter that changes the whole response. Finding those things by hand is tedious and slow. That's the gap ffuf fills—it's a web fuzzer written in Go that automates the guessing so you don't have to.

What It Does

ffuf is a command-line tool that takes a wordlist and fires requests at a target, substituting each word into a spot you define. That spot is marked with the FUZZ keyword, and you can drop it almost anywhere that matters: at the end of a URL path, inside a Host header, or as a GET or POST parameter name or value. Every request goes out, ffuf compares the responses, and you get a list of what came back.

It's written in Go, which is the reason it can churn through large wordlists quickly. The README keeps the examples deliberately simple, but the underlying idea is flexible—the same tool covers content discovery, vhost discovery, and parameter fuzzing without you switching to different software. There's also support for external mutators to generate test cases and configuration files to save your setups.

Why It's Cool

• One keyword, many jobs. The FUZZ keyword is the whole interface. Because you can place it in a URL, a header, or a parameter, you don't need separate tools for directory brute-forcing versus vhost hunting versus parameter testing. That consistency means less context-switching and fewer command syntaxes to remember.

• Filtering is built for real targets. The examples lean on -fs (filter by response size) to strip out noise—like when every invalid vhost returns the same 4242-byte default page. That's a practical acknowledgment that fuzzing produces a lot of false positives, and the tool gives you a way to cut through them rather than drowning you in output.

• Installation is genuinely easy. Prebuilt binaries are on the releases page, and there are package manager routes for Scoop, Winget, and Homebrew. If you've got a recent Go compiler, go install github.com/ffuf/ffuf/v2@latest does the job and doubles as the update command. No dependency wrangling.

• It's honest about builds. The README notes that a build from a checkout reports git-<date>-<commit> rather than a tag, and that local builds aren't official releases. That's a small detail, but it tells you the maintainers care about people knowing exactly what they're running.

• There's somewhere to practice. The README points to ffufme, a Docker container you can run locally, and a hosted version at ffuf.me with lessons and use cases. Being able to try scans against a purpose-built target instead of someone's real server is a nice touch for learning.

How to Try It

1. Install it however suits your setup:

brew install ffuf          # macOS
scoop install ffuf         # Windows with Scoop
winget install ffuf.ffuf   # Windows with Winget
go install github.com/ffuf/ffuf/v2@latest   # with a Go compiler

Or grab a prebuilt binary from the releases page.

1. Run a basic directory discovery against a target, using FUZZ where the wordlist entries should land:

ffuf -w /path/to/wordlist -u https://target/FUZZ

1. Try vhost discovery by fuzzing the Host header and filtering out the default response size:

ffuf -w /path/to/vhost/wordlist -u https://target -H "Host: FUZZ" -fs 4242

1. Fuzz a GET parameter name:

ffuf -w /path/to/paramnames.txt -u https://target/script.php?FUZZ=test_value -fs 4242

The README also covers POST data fuzzing, external mutators, and configuration files, and there's an interactive mode documented under usage. For deeper walkthroughs, the ffuf wiki and Michael Skelton's guide "Everything you need to know about FFUF" are both linked from the repo. You can find the project itself at github.com/ffuf/ffuf.

Final Thoughts

ffuf isn't trying to be everything—it's a focused fuzzer that does a few related jobs well and gets out of your way. If you do any kind of web reconnaissance, whether for security testing or just mapping out an application you've inherited, it's worth having in your toolkit. The learning curve is mostly about picking the right filter, and the practice targets make that easy to work on. Start with a simple directory scan, get a feel for the output, and go from there.