Content Discovery with ffuf: Directory Brute-Forcing Explained

Content discovery is the process of finding files, directories, parameters, and subdomains that exist on a web server but are not linked from its visible navigation. ffuf (Fuzz Faster U Fool) is a fast, open-source Go-based fuzzer that automates this by sending a wordlist of guesses against a target URL and reporting which ones exist, based on HTTP status codes, response size, and word count. For Indian dev and security teams testing their own applications, ffuf-driven content discovery routinely surfaces forgotten admin panels, exposed backup files, and leftover .git directories — all against assets you own or are explicitly authorised to test.

Before anything else: only run ffuf against domains and applications you own, or hold explicit written authorisation to test. Brute-forcing paths on a third-party asset without permission is unauthorised access under India's IT Act, Section 43/66, regardless of intent.

Why Content Discovery Matters in a VAPT Engagement

A web application's visible menu is not its full attack surface. Developers routinely leave behind staging endpoints, old API versions, debug pages, backup archives, and configuration files that were never meant to reach production but were also never removed. None of these show up in a manual click-through of the site — they only surface through systematic guessing against a wordlist.

Content discovery sits early in most VAPT (Vulnerability Assessment and Penetration Testing) workflows, right after passive recon and before deeper exploitation. What it finds directly shapes the rest of the assessment: an exposed .git folder can leak source code and secrets, an unlinked /admin panel becomes a priority authentication target, and a stray backup.zip can hand over a full database dump without a single exploit being run.

How ffuf Works: The Core Loop

ffuf replaces a placeholder — the FUZZ keyword — in a URL, header, or POST body with each word from a wordlist, sends the request, and records the response. A basic directory fuzzing run looks like this:

ffuf -u https://target.example/FUZZ -w wordlist.txt

Because FUZZ can go anywhere in the request, the same tool handles several distinct discovery tasks:

1. Path fuzzing — https://target.example/FUZZ to find directories and files.
2. Parameter fuzzing — https://target.example/api?FUZZ=1 to find hidden query parameters.
3. Virtual host fuzzing — -H "Host: FUZZ.target.example" against a fixed IP to find subdomains that share infrastructure but aren't in DNS.
4. Extension fuzzing — combining a base wordlist with -e .php,.bak,.old to catch forgotten file variants.

Choosing the Right Wordlist

ffuf's output quality is entirely dependent on the wordlist behind it. The most widely used source is SecLists, a community-maintained collection of wordlists for discovery, fuzzing, and payload testing, organised under Discovery/Web-Content/.

Common starting points from SecLists:

Filtering Results: Status, Size, and Words

A raw ffuf run against a real application often returns hundreds of "hits" that are actually noise — usually because a custom error page returns HTTP 200 for every path instead of a proper 404. ffuf handles this through match and filter flags:

1. -mc 200,301,302,403 — match only specific status codes.
2. -fc 404 — filter out a known "not found" status.
3. -fs 4242 — filter out responses of an exact size (the custom-404 page size, once you've identified it).
4. -fw 150 — filter out responses with an exact word count.

ffuf -u https://target.example/FUZZ -w common.txt -mc 200,301,302,403 -fs 4242

Rate limiting is controlled with -rate (requests per second) and -p (delay between requests), and both should be set conservatively — starting around 10–20 requests per second — on anything resembling shared or production infrastructure.

Recursion: Fuzzing Discovered Directories Automatically

Directory structures are rarely flat. ffuf's -recursion flag automatically re-runs the fuzz job against any directory it discovers, up to a configurable depth (-recursion-depth):

ffuf -u https://target.example/FUZZ -w common.txt -recursion -recursion-depth 2

This is how a single /api hit expands into /api/v1, /api/v1/users, and further nested endpoints without manually re-running the tool at each level. Recursion multiplies request volume quickly, so it should always be paired with a tight wordlist and conservative rate limiting rather than the largest raft list available.

These figures, from Verizon's 2024 Data Breach Investigations Report, underline why unmanaged internet-facing assets matter. Old staging paths, forgotten backup files, and unlinked admin panels are a recurring theme in CERT-In's advisories on web application hygiene, and exactly the kind of exposure a fuzz run surfaces before an attacker finds it first.

What Hidden Endpoints Actually Reveal

Content discovery consistently turns up the same categories of exposure across Indian web applications:

1. Admin and management panels (/admin, /manage, /wp-admin, /dashboard-internal) left reachable without IP restriction or additional authentication.
2. Version control artifacts — an exposed .git directory allows an attacker to reconstruct full source code history, including commits that once contained hardcoded secrets even if later removed.
3. Backup and archive files (.zip, .bak, .sql, .tar.gz) left in the webroot after a deployment or migration, often containing full database dumps.
4. Configuration and environment files (.env, config.php.bak, web.config) that leak API keys, database credentials, or internal hostnames.
5. Staging and debug endpoints (/debug, /test, /phpinfo.php) that expose stack traces, server versions, or internal IP addressing.

Validating Findings Before Reporting

A raw ffuf hit is a lead, not a confirmed finding. Every result worth reporting should be manually validated:

1. Load the path directly in a browser or via curl to confirm it actually serves content (not a redirect masking a 404).
2. Check whether the endpoint requires authentication, and if so, whether that authentication is enforced server-side or only hidden from navigation.
3. For files (backups, configs), confirm they contain live, current data rather than stale artifacts from years ago.
4. Cross-reference against the rest of the recon — does this endpoint match a known framework's default admin path, or is it custom to this application?

Defensive Response: Closing What ffuf Finds

Running ffuf against your own application is only half the value — the response matters more:

1. Remove or restrict exposed files immediately. Delete backup archives and .git directories from the webroot; they should never have been deployed there in the first place. Move genuinely needed admin panels behind IP allow-listing or VPN access, not obscurity.
2. Monitor for 404 bursts. A sudden spike in 404 responses from a single source IP in a short window is a strong signal of directory brute-forcing in progress, whether from an authorised scan or a real attacker. Web server logs, a WAF, or a basic rate-based alert rule can catch this pattern.
3. Add a custom 404 with a consistent size and status code. This removes the ambiguity that lets attackers (or noisy scans) mistake soft-404 pages for real content, and makes your own filtering cleaner on the next authorised run.
4. Re-run discovery after every deployment. Staging debug routes and stray backup files tend to reappear with new releases, not just at initial launch.

Content discovery is one layer of a full assessment. Bachao.AI, built by Dhisattva AI Pvt Ltd, helps Indian teams run this kind of testing continuously against their own assets as part of a broader, audit-ready VAPT process, including cases that need a report delivered with a CERT-In empanelled partner. If you want an outside baseline on what's actually reachable on your domain, start with a free VAPT scan. For obligations around personal data exposed through misconfigured endpoints, see our guide on DPDP compliance, and browse more testing write-ups on the Bachao.AI blog.