ffuf: Fast Web Fuzzer Usage, Wordlists and Detection

ffuf (Fuzz Faster U Fool) is a free, open-source web fuzzer written in Go that substitutes words from a list into any part of an HTTP request and reports the responses that stand out. Testers and attackers use it to find what a web application or API serves but never links to: backup files, admin consoles, staging virtual hosts, hidden parameters and retired API versions. If you own the application, the useful questions are what ffuf would find, whether your logs would show the run, and which fixes leave it nothing to find.

This guide answers each, and shows how a web application penetration test or API penetration test uses the same technique, with published web app pricing from $5,200 and a free retest.

What ffuf is, and what web fuzzing means here

In classic security testing, fuzzing means feeding malformed input to a program until it misbehaves. ffuf does something narrower: dictionary-driven fuzzing of web requests. The operator marks a position (the URL path, a parameter name or value, a header such as Host, a cookie or the body) with a placeholder keyword, FUZZ by default, and ffuf sends one request per wordlist entry. It can replay a raw request saved from an intercepting proxy, session cookie included, so fuzzing behind a login is routine. It can also recurse into directories it finds, append extensions to every word, combine wordlists in lockstep or in every combination, and pass hits to a proxy for manual follow-up.

Filtering is where ffuf earns its reputation. Matchers and filters keep or drop responses by status code, size, word or line count, regular expression or response time, and auto-calibration learns the target’s “not found” response, so a custom error page that returns 200 does not bury real hits.

MITRE ATT&CK classifies this as Active Scanning: Wordlist Scanning (T1595.003) and lists APT41 brute-forcing web server directories among its procedure examples.

Facts that matter to defenders, as of November 2026:

• Release. Version 2.3.0 shipped on September 9, 2026, under the MIT license (ffuf releases).
• Defaults. Per the ffuf manual page, 40 concurrent threads and no request-rate cap unless the operator sets one.
• What counts as a hit. Status codes 200-299, 301, 302, 307, 401, 403, 405 and 500 by default. A 403 counts, because it tells the operator the path exists.
• How it identifies itself. Unless overridden, every request carries the User-Agent “Fuzz Faster U Fool” plus the version number.
• Anti-CSRF tokens. Version 2.3.0 added preflight requests that fetch a value, such as a fresh anti-CSRF token, and carry it into the next fuzzing request, so per-request tokens alone do not stop automation.

What ffuf is used for: six jobs and what a hit means

ffuf usage comes down to where the word goes, and each placement points to a different weakness:

Job	Where the word goes	What a hit usually means	Reference
Content discovery	URL path, file names and extensions	Exposed backups, .git or .env files, admin consoles, forgotten uploads	WSTG-CONF-04
Virtual host discovery	Host header, against a known IP	A staging or internal site with no public DNS record	WSTG-INFO-04
API version discovery	Version numbers and resource names in the path	An old API version still answering, often without production’s controls	API9:2023
Parameter discovery	Query-string or body parameter names	A debug, admin or legacy parameter the front end never sends	WSTG-CONF-05
Identifier fuzzing	Parameter values and object IDs	Other users’ records returned: broken object-level authorization	API1:2023
Login and code guessing	Username, password or one-time-code fields	No working lockout or rate limit	WSTG-ATHN-03

The first four jobs find surface; the last two test its controls, and they are where fuzzing becomes a high-severity finding: an IDOR vulnerability proven across thousands of identifiers, or a one-time code with no attempt limit. Our OWASP API Security Top 10 explainer covers the API categories above, and our API penetration testing checklist gives the full method that follows the fuzzing step.

ffuf command patterns and what each flag does

You will meet ffuf commands in penetration test reports and incident write-ups, so it helps to read them. These three patterns follow the examples in the ffuf manual page linked above: content discovery, virtual host discovery and parameter fuzzing.

ffuf -w wordlist.txt -u https://example.org/FUZZ
ffuf -w hosts.txt -u https://example.org/ -H "Host: FUZZ" -mc 200
ffuf -w params.txt:PARAM -w values.txt:VAL -u "https://example.org/?PARAM=VAL"

Flag	What it does	What it means for your logs
-w	Wordlist path, optionally with its own keyword	One request per entry
-u	Target URL; the keyword marks what varies	The path or parameter that changes on each request
-H	Adds a header; with the keyword in Host it becomes virtual host discovery	Many Host values sent to one IP
-mc, -fc, -fs, -fw	Match or filter responses by status code, size or word count	Nothing: filtering happens on the operator’s side
-ac	Calibrates the filters automatically (off by default)	Nothing you can alert on
-t	Concurrent threads, 40 by default	The size of the burst
-rate, -p	Requests per second (0, no cap, by default) and a delay between requests	A slow run that stays under volume alerts
-e	Appends extensions to every word	Requests for names ending .bak, .old and similar
-recursion	Scans again inside each directory it finds	Bursts that move deeper into one path
-request	Replays a raw HTTP request saved from a proxy	Authenticated traffic carrying a real session cookie

ffuf wordlists: why obscure names are not a control

ffuf only finds names in its list, so the wordlist decides the result. Testers draw on four kinds:

• Public collections. SecLists is the best known: common directory, file, parameter and subdomain names from real software.
• Technology-specific lists. Once the stack is known, the list narrows to its defaults, such as the Tomcat, WordPress, Spring Boot Actuator, Jenkins script console and Kubernetes Dashboard paths in OWASP’s admin-interface test.
• Target-built lists. Names harvested from your own JavaScript bundles, robots.txt, sitemap and HTML comments. OWASP’s backup-file test describes inference from naming: if a viewuser page exists, try edituser and adduser.
• Extension mutation. Appending .bak, .old, .orig or a tilde to files already found, which is how editor and deployment leftovers surface.

An unusual path name slows a generic list, but a target-built list closes most of the gap. The weakness underneath is CWE-425, Direct Request, often called forced browsing: restricted URLs that do not enforce authorization. The fix is authorization on every route, not a better-hidden path.

ffuf vs Gobuster, feroxbuster, wfuzz and Burp Intruder

Our Gobuster explainer sets ffuf, Gobuster and feroxbuster side by side. Gobuster has dedicated modes for DNS subdomains and cloud storage buckets; ffuf is stronger at complex placements: several keywords with their own wordlists, finer filtering, auto-calibration and raw-request replay. feroxbuster, written in Rust, recurses into found directories automatically; wfuzz is the older Python fuzzer with the same FUZZ keyword; Burp Suite’s Intruder fuzzes positions inside the proxy (our Burp Suite vs a penetration test page covers what the tool does and does not replace). For a defender the traffic looks the same. A port scanner such as Masscan finds the web services to aim at first, and our guide to penetration testing tools shows where each fits.

None of these is a vulnerability scanner. A fuzzer reports which responses stand out and leaves the judgment to the operator, while DAST tools crawl an application and test what they find for known vulnerability classes.

How to detect ffuf in your logs

At default settings ffuf is loud, but its delay and rate options let a patient operator spread a run over hours, so volume alerts catch only the careless run. The signals worth wiring up:

Signal	Log source and field	What it indicates	Notes
A burst of 404s from one client	Web server, CDN or load balancer access logs: status and client IP	Content discovery	Alert on the 404 ratio per source, not the raw count
Many responses of identical size	Response size: $body_bytes_sent in NGINX’s combined format; sc-bytes in IIS	A fuzzer iterating against one error page	IIS logs bytes sent by default only since the February 2026 update, on Windows Server 2019 and later
User-Agent containing “Fuzz Faster U Fool”	User-Agent field, logged by default in NGINX and IIS	A default ffuf run	Trivially changed: a tripwire, not a control
Many distinct Host values to one IP	Proxy or web server logs with Host recorded	Virtual host discovery	Not in NGINX’s combined format or IIS defaults: add it
One path, dozens of parameter names or sequential IDs	Application and WAF logs with the query string	Parameter or identifier fuzzing	Pair with authorization-failure logging
Requests for .git, .env or backup extensions	Access logs, WAF managed-rule matches	Sensitive-file probing	Internet scanners probe these constantly: alert when one is served, not on the request
Failed logins or code attempts on one account or source	Application and identity provider sign-in logs	Credential or code guessing	Alert per account and per source

Logging defaults come from NGINX’s log module reference and Microsoft’s IIS logFile reference. A decoy path nothing links to, named like a wordlist entry, adds cheap signal, but internet scanners hit it too: escalate when the same source also shows the 404 burst or Host-header pattern, or the request comes from inside your network.

Two illustrative lines in NGINX’s combined format show the first three signals together: one client, 404s of identical size, and the default User-Agent.

203.0.113.7 - - [07/Nov/2026:14:02:11 +0000] "GET /backup HTTP/1.1" 404 153 "-" "Fuzz Faster U Fool v2.3.0"
203.0.113.7 - - [07/Nov/2026:14:02:11 +0000] "GET /admin.bak HTTP/1.1" 404 153 "-" "Fuzz Faster U Fool v2.3.0"

For the 404 ratio rule, a workable starting point is one source sending more than 50 requests in five minutes with over 90% of them returning 404. Tune both numbers to your own traffic, because crawlers and broken links produce 404s too.

How to prevent and reduce what ffuf finds

Detection tells you a run happened; these controls make it come back empty:

1. Ship only what should be served. Deploy an explicit set of build artifacts, keep configuration, logs and data outside the web root, and never edit files in place on production, because editors leave backups behind. WSTG-CONF-04 makes the same recommendations.
2. Serve each extension with its intended handler or not at all, and disable directory listing.
3. Take non-production off the public edge. Put staging and internal virtual hosts behind VPN, single sign-on or an IP allowlist, and add a catch-all default virtual host that returns a neutral response to unknown Host values.
4. Enforce authorization on every route and object. Assume every path and identifier is known.
5. Inventory and retire API versions. API9:2023 asks for an inventory of every API host and version, with the same external protection on all exposed versions, not only production.
6. Rate-limit per source and per account, stricter on password reset and one-time codes, as API4:2023 recommends, and on login, as WSTG-ATHN-03 describes. An AWS WAF rate-based rule looks back over 60, 120, 300 or 600 seconds and accepts a limit as low as 10 requests, per the AWS WAF documentation.
7. Make responses less informative. Use consistent error pages, and consider 404 rather than 403 for resources a caller has no business knowing exist. Auto-calibration sees through soft-404 pages, so this only reduces signal.
8. Run discovery against yourself on a schedule. External attack surface management keeps the footprint mapped between tests.

How Invadel tests for it, and what it costs

Content, virtual host and parameter discovery belong to the mapping stage of every web application penetration test and API penetration test, where every endpoint, parameter and integration is enumerated before a single payload is sent; identifier and login fuzzing come later, when authorization and abuse controls are tested. The tool matters less than the steering: wordlists built for your stack and naming, authenticated runs for each user role, and every hit checked by hand before it becomes a finding, as one layer of full web application security testing.

Testing stays inside the signed scope, at a request rate agreed in writing. We test staging where it exists; where production is the only option, the rules of engagement exclude denial-of-service techniques and set testing windows. Anything critical is escalated the day it is confirmed. Each finding carries a CVSS rating, a CWE mapping, reproduction steps and the fix, and the free retest confirms it: the backup file returns 404, the old API version no longer answers, the code form locks.

Engagement (published starting price)	Small	Medium	Large
Web application	$5,200	$7,800	$12,500+
API	$4,000	$6,000	$9,500+
External network (subdomains and perimeter)	$4,200	$6,800	$8,400

Each price is fixed in writing from your scope details, with no sales call. Each exposed path, host, API version or parameter the discovery pass confirms becomes a finding in the technical report with its CVSS rating, the executive report summarizes them by severity, and the attestation letter and the retest above are included. Tiers and cost drivers are on the web application pricing page, the API pricing page and the external network pricing page; the cost calculator totals several tests, and a sample report shows the write-up.

Whoever you hire, get the source addresses and test windows in advance; if the discovery phase raised no alert, that gap belongs in the remediation plan.

Frequently asked questions

What is ffuf used for? Finding what a web application or API serves but does not link to, and testing at scale whether object IDs leak other users’ records or a login form enforces lockout.

What does the FUZZ keyword mean in ffuf? It marks the position in the request where ffuf substitutes each word from the list: a path segment, a parameter name or value, a header or part of the body. Extra wordlists can carry their own keywords.

How many requests does ffuf send per second by default? There is no fixed number. The default is 40 concurrent threads with no rate cap, so the speed depends on how fast the server answers. The -rate option sets a ceiling.

Does ffuf run on Windows? Yes. It is written in Go and runs on Windows, Linux and macOS, so any workstation can run it, not only a Kali Linux machine.

Is ffuf better than Gobuster? For DNS subdomains and storage buckets, Gobuster’s dedicated modes are simpler; for parameters, headers, multi-position requests and noisy targets, ffuf’s filtering and auto-calibration save time. The wordlist matters more than either tool.

What wordlist does ffuf use? Whatever the operator supplies, usually SecLists plus lists built for the target’s technology and naming.

Can a WAF stop ffuf? It can slow and flag default runs through rate-based rules, user-agent matches and managed rules for sensitive file names, but not a patient operator spreading requests over time and sources. The durable fix is removing what the run would find.

Can I run ffuf against my own website? Only against systems you own or have written authorization to test, and check your hosting or CDN terms first. Keep the rate low on production: the default of 40 threads with no rate cap can strain a small application.

The short version

ffuf finds what your application serves but never advertises, and tests whether IDs, parameters and login forms hold up under thousands of attempts. Default runs are easy to spot in access logs; careful runs are not, so the real defense is shipping only what should be served, keeping non-production off the public edge and enforcing authorization on every route. A web application penetration test shows what a fuzzing pass would turn up, from $5,200 with a free retest: send your scope for a fixed quote.