ffuf brute forces hidden paths and apis

the hidden pages problem

every website has more pages than the ones in the nav menu. old backup folders someone forgot to delete, a staging api that never got locked down, a .git directory that got deployed by accident. nobody links to these pages, but they still exist, and if a url exists, someone can request it. the tool that finds these is called ffuf, and if you run websites or apps for a living, you need to understand exactly what it's doing, because attackers already do.

what ffuf actually does

ffuf stands for "fuzz faster u fool." it's a brute force tool that takes a wordlist of common path names and slams them against your site one by one, watching what comes back. here's the command from the reel:

ffuf -u https://target/FUZZ -w raft-medium.txt -mc 200,301,403 -c

breaking that down:

-u https://target/FUZZ is the target url, and FUZZ is a placeholder. ffuf swaps that placeholder with every word in the wordlist, one request at a time.

-w raft-medium.txt is the wordlist. raft is a popular list of real-world directory and file names pulled from actual web crawls, things like /backup, /admin, /.git, /config.old, /api/v1. this isn't random guessing, it's guessing informed by patterns that show up constantly across the internet because developers make the same mistakes everywhere.

-mc 200,301,403 tells ffuf which http status codes to actually show you. 200 means the page loaded, 301 means it redirected somewhere (often a sign a real folder exists), and 403 means forbidden, which is interesting because it confirms something is there, it's just blocking direct access. ffuf throws away all the noise (like the thousand 404s) and only surfaces the responses that matter.

-c just adds color to the output so it's easier to read in a terminal. purely cosmetic.

then it goes deeper

once a hidden path turns up, like /api/, the next move is to fuzz inside it:

ffuf -u https://target/api/FUZZ -w api-words.txt -mc 200

this recursion is the real danger for defenders. finding one exposed folder is rarely the end goal, it's a doorway. an exposed /api/ folder gets fuzzed for endpoints like /api/users, /api/debug, or /api/v1/export, and suddenly someone has found an internal endpoint that was never meant to be public.

why this matters if you run a site

the uncomfortable truth is that "security through the page not being linked anywhere" is not security. it's just hoping nobody looks. ffuf and tools like it (gobuster, dirsearch, feroxbuster) are free, fast, and run against thousands of paths in minutes. if your exposure exists, someone will find it, whether that's a curious researcher, a bug bounty hunter, or someone with worse intentions.

how to defend your own attack surface

the fix isn't complicated, it's just discipline that a lot of teams skip under deadline pressure.

run ffuf against your own domains before someone else does. that's the whole point of tools like this existing openly, use them on your own infrastructure first.

ffuf -u https://yourdomain.com/FUZZ -w raft-medium.txt -mc 200,301,403 -c

then go fix what you find:

delete backup files and old folders from production. .bak, .old, .zip, .tar.gz files sitting in a web root are a gift to anyone scanning.

never deploy your .git directory to a live server. if you're not sure, check for it yourself, it's one of the most common accidental leaks and it can hand over your entire source history.

put real authentication on internal or admin apis instead of relying on the url being obscure. "nobody knows this endpoint exists" is not access control.

use a web application firewall or rate limiting to slow down or block obvious brute force scanning patterns, since ffuf traffic has a recognizable shape (rapid sequential requests hitting nonexistent paths).

log and alert on spikes of 404s and 403s from a single ip, that's usually the fingerprint of someone fuzzing your site.

the takeaway

the attack surface you can see is never the whole attack surface, and that cuts both ways. if you don't know what's actually exposed on your own domain, you're behind before anyone even starts looking. run the scan on yourself, clean up what you find, and put real access control on anything that matters. the goal isn't to hide your endpoints better, it's to make sure it doesn't matter if someone finds them.