# ffuf
ffuf (Fuzz Faster U Fool) is an open-source web fuzzing tool written in Go, designed to automate the discovery of hidden resources, parameters, and virtual hosts within web applications. Security professionals use it during reconnaissance and vulnerability assessment phases to surface attack surface components that are not visible through normal browsing or API documentation. Before tools like ffuf, testers relied on slower, less flexible alternatives that struggled with modern web architectures. ffuf addresses that gap by combining high-speed HTTP request generation with granular filtering controls, making it practical for both rapid assessments and deep, systematic enumeration across complex applications. Its design philosophy prioritizes operational speed without sacrificing accuracy or control.
---
ffuf is a command-line HTTP fuzzing tool that substitutes a placeholder keyword, by default FUZZ, into any component of an HTTP request: the URL path, query string, headers, or POST body. It then iterates through a wordlist, sending one request per entry, and evaluates each response against configurable match and filter rules to identify anomalies that indicate real resources or functionality.
ffuf is not a vulnerability scanner. It does not identify SQL injection, cross-site scripting, or other specific vulnerability classes by itself. It is a discovery engine: it tells the tester what exists, not necessarily whether what exists is exploitable. That distinction matters when scoping engagements and reporting findings. A directory found by ffuf requires separate exploitation testing.
ffuf is also distinct from brute-force password tools like Hydra or Medusa, which target authentication endpoints with credential pairs. While ffuf can fuzz login parameters, its primary design is surface enumeration rather than credential stuffing.
Variants of ffuf usage include: directory and file brute-forcing, virtual host (vhost) enumeration, GET and POST parameter name discovery, parameter value fuzzing, API endpoint discovery, subdomain enumeration (when combined with DNS-aware proxy configurations), and multi-position fuzzing using FUZZ, W2, and additional keywords simultaneously with different wordlists. The tool supports recursive mode, where newly discovered directories are automatically queued for further fuzzing, which is critical for deeply nested application structures.
ffuf is distinct from passive reconnaissance tools. It generates active traffic against a target and will appear in server logs, WAF alerts, and intrusion detection systems unless rate-limited or otherwise obfuscated.
---
ffuf operates on a straightforward substitution model. The tester constructs an HTTP request template containing one or more placeholder keywords. ffuf reads entries from one or more wordlists and replaces the placeholder with each entry, dispatches the request, receives the response, and evaluates the response against user-defined match and filter criteria. Requests that pass the criteria are reported as hits.
Request Construction
The most common invocation targets URL path discovery:
ffuf -w /usr/share/wordlists/dirb/common.txt -u https://target.example.com/FUZZHere, FUZZ is replaced sequentially with every word in the wordlist. For a 4,000-word list and default concurrency of 40 threads, ffuf can complete the scan in seconds depending on server response time.
For virtual host enumeration, the placeholder moves to the Host header:
ffuf -w vhosts.txt -u https://10.10.10.50/ -H "Host: FUZZ.target.example.com"This technique identifies applications served on undocumented subdomains or internal hostnames behind a shared IP address, a common configuration in containerized and microservices environments.
For POST parameter discovery, the placeholder moves into the request body:
ffuf -w params.txt -u https://target.example.com/login -X POST -d "FUZZ=test" -H "Content-Type: application/x-www-form-urlencoded"Multi-Position Fuzzing
When testing parameter values simultaneously with parameter names, ffuf supports multiple keywords mapped to separate wordlists using the -w flag with a colon-delimited label:
ffuf -w params.txt:PARAM -w values.txt:VAL -u https://target.example.com/search?PARAM=VALThis is particularly useful for API fuzzing where both the field name and acceptable value range are unknown.
Filtering and Matching
Raw fuzzing produces noise. Every response needs evaluation. ffuf provides two filtering mechanisms: match rules (include responses that meet the condition) and filter rules (exclude responses that meet the condition).
Common filters:
-fc 404 filters out 404 Not Found responses, the default noise in directory brute-forcing.-fs 1234 filters responses with a specific byte size, useful when a server returns 200 OK for all requests but with a consistent error page body size.-fw 10 filters by word count in the response body.-fl 30 filters by line count.-fr "Not Found" filters by regex match in the response body.The -ac (auto-calibration) flag sends several probe requests to establish baseline response characteristics and automatically sets filter thresholds. This is valuable when testing targets that return 200 OK with custom error messages rather than proper HTTP status codes, a design pattern common in single-page applications.
Recursion
With -recursion and -recursion-depth flags, ffuf automatically queues newly discovered directories for further fuzzing. If /api/ is discovered, ffuf will then fuzz /api/FUZZ, and so on to the specified depth. This is essential for finding nested endpoints that would otherwise require manual follow-up.
Practical Scenario: API Endpoint Discovery During a Web Application Pentest
Consider a penetration test against a SaaS platform. The application's documented API exposes /api/v1/users and /api/v1/orders. The tester suspects undocumented endpoints exist. Using a curated API wordlist (such as those from SecLists' Discovery/Web-Content/api/ directory), ffuf fuzzes the path:
ffuf -w api_endpoints.txt -u https://app.target.com/api/v1/FUZZ -mc 200,201,204,401,403Matching on 401 and 403 in addition to success codes is deliberate: a 403 Forbidden response still confirms the endpoint exists and that authentication is required, which is actionable intelligence. The tester discovers /api/v1/admin, /api/v1/export, and /api/v1/debug, none of which appeared in documentation. The /api/v1/debug endpoint, returning 200 OK with verbose application internals, becomes the critical finding of the engagement.
Performance Controls
ffuf's -t flag sets thread count, and -rate caps requests per second. These controls are important not just to avoid overwhelming a target but also to stay within engagement scope limits. Many rules of engagement specify maximum request rates. The -p flag introduces a delay between requests, and -timeout sets per-request timeout thresholds.
---
Hidden attack surface is exploited attack surface. Web applications routinely contain directories, endpoints, parameters, and virtual hosts that developers deployed but never documented, removed from navigation but never deleted, or left in place as legacy functionality. These components often bypass normal security controls because they were never subject to security review. ffuf is the primary operational tool for finding them.
The security impact is direct. A forgotten administrative panel accessible at /admin-legacy/ may lack authentication entirely. An undocumented parameter like ?debug=true may expose stack traces and internal application state. A virtual host serving a staging environment on the same production IP may run months-old software with known critical vulnerabilities. None of these findings emerge from static analysis or passive monitoring alone. They require active enumeration.
Real-World Consequence: The Tesla Kubernetes Dashboard Incident
In 2018, security researchers at RedLock discovered that Tesla's Kubernetes management console was exposed to the public internet without a password. The console was not linked from any public-facing page. Attackers had already discovered it, gained access, and were running cryptomining workloads inside Tesla's cloud infrastructure. The console endpoint was discoverable through exactly the kind of unauthenticated directory and service enumeration that tools like ffuf automate. Tesla's incident illustrated that security controls applied to known surfaces do nothing for unknown surfaces, and unknown surfaces are found through systematic enumeration.
Common Misconceptions
One frequent misconception is that HTTPS encryption prevents enumeration. Encryption protects data in transit but does nothing to obscure which resources exist on a server. ffuf operates at the HTTP layer over TLS without impediment.
Another misconception is that WAFs prevent ffuf from being effective. A WAF may rate-limit or block high-volume fuzzing runs, but a patient tester using low request rates, varied user agents, and filtered wordlists can enumerate most surfaces that WAFs are configured to allow for legitimate users.
A third misconception is that security through obscurity is sufficient for internal or staging resources. The Tesla case, and numerous HackerOne disclosed reports, demonstrate that obscurity without access control provides no real protection.
---
CDA approaches ffuf not as an offensive curiosity but as a foundational instrument within the Planetary Defense Model's Vulnerability Surface Discovery (VSD) domain. The core CSR methodology, "Every surface you expose is a surface we eliminate," begins with knowing what surfaces exist. You cannot eliminate what you have not found.
CDA uses ffuf as part of structured, recurring surface enumeration operations rather than one-time point-in-time assessments. A surface discovered today may not have existed six months ago: deployments, infrastructure changes, and developer shortcuts continuously expand the attack surface between assessments. CDA's CSR cadence incorporates automated ffuf runs against client environments on a defined schedule, with results compared against prior baselines to identify newly emerged surfaces.
Operationally, CDA maintains curated, client-specific wordlists that grow with each engagement. Generic wordlists like SecLists' common.txt are starting points. CDA augments them with application-specific terms derived from JavaScript source analysis, sitemap crawling, and prior engagement history. This increases discovery fidelity and reduces noise.
CDA also applies ffuf in the vhost enumeration context specifically to identify shadow IT and rogue deployments. Development teams frequently spin up virtual hosts on production infrastructure without formal change management. These hosts often run without security hardening or monitoring. Identifying them is a prerequisite to bringing them under control.
Results from ffuf runs feed directly into CDA's surface inventory, which is the authoritative record of every confirmed, accessible endpoint associated with a client's environment. From that inventory, CDA prioritizes remediation by criticality: unauthenticated administrative panels and exposed debug endpoints are addressed immediately, while low-risk informational directories are tracked and scheduled for removal.
What CDA does differently is treat ffuf output as structured operational data rather than a raw report artifact. Every discovered endpoint is tagged, categorized, and tracked through resolution, creating a closed-loop process aligned with CSR's elimination mandate.
---
-ac; run calibration before trusting hit counts.---
---