FFUF wordlist comparisons need a shared baseline and a visible classification rule. Record the request conditions, normalized candidate set, filters and a permitted review sample. Compare useful coverage under the same workload limits instead of assuming the largest list is the best fit.
Sources, review date and section shortcuts
Key claims reviewed: October 19, 2026. No wordlist is universally best; compare relevant coverage, requests and response classification under the same conditions.
Primary documentation · Related practical guide
Go straight to: Decision check · Main workflow · Further detail
Open the Wordlist comparison ledger for this guide’s task-specific fields and next action.
Record the filter before comparing wordlists
Keep target scope, request template, authentication state, rate/concurrency limits and stop conditions constant. Save representative wildcard and error responses before choosing filters. Auto-calibration can help classification but may suppress a real result, so retain the filter configuration and spot-check permitted samples. A larger candidate count is not evidence of better useful coverage. Compare normalized unique candidates and valid discoveries, not just elapsed time or status-code totals. Source and scope.
FFUF wordlist tuning starts with the response baseline. Use a small list such as common.txt for a quick first pass, then consider a Raft directory list when the application and remaining scope justify more coverage. Neither name guarantees better results. First learn what a known page, a missing path and a login redirect look like on your authorized target.
Quick path: check three control paths → run a bounded sample → validate any filter. All commands below are examples for one lab web application you own or have explicit permission to test. Replace the placeholders; no requests were executed for this article.
Choose a list for a specific question
- common.txt: a reasonable starting candidate when you need a quick breadth check. Its contents depend on the project and revision; record which file you actually used.
- Raft directories: consider
raft-small-directories.txtbefore a larger directory list when your question concerns directory names. File-name lists answer a different question. - A custom list: useful when permitted observations suggest application-specific paths. Preserve exact case where relevant; lowercasing can remove meaningful distinctions.
The SecLists Web-Content directory lists the current common and Raft variants. Locate the installed file on your own system rather than assuming every Kali installation uses the same path. Choose by contents, question and request budget—not a fixed claim that one list always wins.
A larger list does not repair a wrong virtual host, an expired session, a broken connection or a response that looks identical for every path. Resolve those first. Two interesting responses can justify investigating those paths; they do not prove that recursive enumeration will be useful.
Set the lab boundary before a run
- Confirm the exact scheme, host, port and allowed path prefix. Use only that target. Do not reuse a work, school or public-service address as a convenient example.
- Agree a request rate and stop conditions with the owner. Even 10 requests per second can be too much for a fragile lab. Stop on instability, rate limiting, repeated server errors or unexpected out-of-scope behavior.
- Identify routes that must not be requested, including state-changing or sensitive endpoints. A wordlist request is still an interaction with the application.
- Check
ffuf -V,ffuf -hand any existingffufrc. Saved configuration can add headers, recursion or other options; inspect it before trusting a command’s apparent scope.
About the retained infographic: its “two-hit” trigger and sample timings are illustrative heuristics, not validated thresholds or completion promises. Two distinct responses do not establish that a larger list or recursion will help. Use the controls, workload limits and evidence-based comparison below.
Check a known page and missing-path controls
In the following shell examples, replace LAB_IP with your authorized lab host and known-page with a harmless route you already know exists. If the application requires a hostname, use its configured lab URL; scanning an IP that reaches a default site answers a different question.
BASE='http://LAB_IP'
printf '%s\n' \
'known-page' \
'missing-check-a-7c82' \
'missing-check-b-4e19' > controls.txt
ffuf -w controls.txt \
-u "$BASE/FUZZ" -mc all \
-rate 2 -t 1 -maxtime 30 \
-of json -o controls.jsonThe two unusual paths are candidate missing controls, not a mathematical guarantee of absence. Confirm their meaning in this lab. Compare status, response size, words and redirect destination; inspect the relevant response body when those signals are ambiguous. A branded error page can return 200, and an authentication redirect can make many different paths appear identical.
The explicit -mc all keeps error-status responses visible during this diagnostic run. Redirects are not followed by default; do not add -r just to make an apparent error disappear. First check whether the destination is expected and in scope. Consult the FFUF option reference for the installed version’s behavior.
Run a bounded sample before expanding coverage
Set WORDLIST to a real readable file. The following uses only its first 200 lines as a workload check. It is an intentionally limited sample, not a representative test of everything the full list might find. The control run above must work first.
WORDLIST='/absolute/path/to/common.txt'
test -r "$WORDLIST" && \
head -n 200 "$WORDLIST" > sample.txt
# Run only after the file check succeeds.
ffuf -w sample.txt \
-u "$BASE/FUZZ" -mc all \
-rate 10 -t 2 -maxtime 60 \
-of json -o sample-common.jsonIf the file check fails, stop and correct the path; do not run with a stale sample.txt from an earlier exercise. The sample applies a request rate, concurrency limit and whole-run time limit. A time-limited run may end before all entries are tried. Record that as partial coverage, even if it returned zero interesting matches.
To compare a Raft candidate, select its actual file and repeat the same bounded method with a different output filename. Keep the target, session, rate, time limit and matching rules consistent. Compare manually confirmed useful paths, repeated error patterns and operational cost. Do not declare a winner from raw match counts alone.
Filter a demonstrated pattern without hiding evidence
Suppose repeated, independently checked missing controls have a stable 1234-byte response. That number is illustrative. A size exclusion might be useful only after you confirm that the known-good control has a different size. Dynamic tokens or timestamps can make size unstable.
# Illustrative value: replace with observed evidence.
# Re-run the controls before applying to a wordlist.
ffuf -w controls.txt \
-u "$BASE/FUZZ" -mc all -fs 1234 \
-rate 2 -t 1 -maxtime 30 \
-of json -o controls-filtered.jsonCompare this output with the unfiltered controls. The expected real route must remain visible. If it disappears, the filter is not suitable. Preserve the unfiltered evidence because a filtered results file does not prove which legitimate results might have been suppressed.
-fsfilters response size;-fwfilters word count;-frfilters a regular-expression match in responses. Choose only a pattern you have inspected.- When combining filters, check
-fmode: the documented default is OR, so matching any exclusion can remove a result. Adding filters is not automatically more precise. - Do not discard every 403 or redirect by habit. A forbidden path or authentication boundary may be relevant, while a 200 may be an error page.
- Automatic calibration with
-acadds its own requests and can still hide useful responses. Treat it as a proposed filter and validate it against controls.
Interpret the outcome and choose one next step
- Almost everything looks identical: inspect a few representative bodies and redirects. Revisit the hostname, session and error baseline. Increasing list size usually just repeats the ambiguity.
- 429 responses or instability: stop, preserve the evidence and ask the owner about recovery and a lower workload. Do not evade rate limits.
- A few distinct paths: verify those harmlessly within scope and record why they matter. Do not label a path a vulnerability from its name alone.
- No useful paths: report what was attempted and whether the run completed. Consider case, allowed extensions or a different list only when an observation gives you a reason.
Extensions, multiple input positions and recursion can multiply work. Keep them off during the initial comparison. A rough requests/rate calculation estimates a minimum transfer time; delays, retries and server behavior change the real duration. Use the tool’s actual progress and stop conditions instead of promising a completion time.
Keep a reproducible tuning note
Target and permitted prefix:
Owner permission / stop conditions:
FFUF version / config reviewed:
Wordlist source, revision and path:
Controls and observed error pattern:
Rate / concurrency / time limit:
Matcher and filter decisions:
Completed or partial coverage:
Manually confirmed paths:
Next question:For your report, separate observations from interpretation and preserve limitations. The practice report outline provides a compact structure. Do not use an actual exam report as a public portfolio sample.
The existing video is retained as optional background. Use the written procedure and primary sources for the scope, commands and limitations of this guide.
Sources and review scope
Reviewed October 9, 2026 (Asia/Seoul): FFUF’s official repository and option documentation and the SecLists wordlist directory. These commands are documentation-based lab examples, not benchmark results, a performed scan or a guaranteed OSCP strategy.
Wordlist comparison ledger
Use these fields to turn this guide into a record for your own task. Keep the actual scope, evidence and unresolved questions together.
On a small screen, scroll the table sideways to read all columns.
| Field | What to record | Your evidence / next check |
|---|---|---|
| Shared baseline | Record target, request template, identity and approved workload. | To complete |
| Candidate set | Identify normalized unique inputs and the list revision. | To complete |
| Classification rule | Preserve wildcard samples, filters and calibration behavior. | To complete |
| Review sample | Record valid discoveries and permitted checks for suppressed results. | To complete |
Next action: Compare useful coverage under the same conditions instead of list size alone.
Related task: Use Kioptrix HTTP Enumeration: Requests and Server Clues for that separate part of the workflow.
Worksheet change record — October 20, 2026
Added four task-specific fields, a next action and a related guide. This is a blank editorial working aid, not a completed test or validated assessment. Existing source-review dates retain their own scope; this addition is not a new verification of every statement.
FFUF comparison example: counts without a performance claim
This fictional planning example illustrates the comparison record. It is not output from a live scan, a benchmark or evidence that a particular wordlist performs better. Assume an authorized training application, a fixed request template and an approved ceiling of 1,000 total requests for the exercise. Keep that ceiling separate from the number of candidate words: baseline checks and permitted validation requests also need room in the plan.
Suppose list A contains 500 normalized unique candidates and list B contains 700, with 400 candidates shared between them. The union contains 800 candidates: 500 plus 700 minus the 400 repeated inputs. Running both lists independently would submit the repeated candidates again. This arithmetic describes candidate overlap only. Redirect handling, calibration, additional request behavior and validation can change the actual request total, so record the observed total separately.
Now imagine that one permitted pass produces twelve response candidates after filtering. Review each against the known-page and missing-path baselines under the same account and request conditions. In a fictional disposition log, four may be distinct intended resources, five may reproduce the generic response, and three may remain unresolved. Keep those categories separate. Twelve displayed rows do not mean twelve findings, and four distinct resources do not by themselves mean four vulnerabilities.
Use the unresolved items to decide the next small check. Write what observation would distinguish a generic response from a meaningful application difference, and reserve enough of the agreed request budget for that check. If the budget is exhausted, preserve the candidates as unresolved rather than silently expanding the run. A paused investigation is still useful when its inputs, classification rule and remaining question can be retrieved later.
For a fair comparison, do not change the identity, filter and candidate set at the same time. If a later exercise changes one of them, start a new record and explain the difference. Keep the wordlist revision, exact normalization rule, relevant configuration and actual workload beside the disposition log. This lets another reader understand the comparison without assuming that elapsed time, list size or response count established superior coverage.
Questions to settle before comparing the next FFUF pass
What should an unresolved candidate contain?
Keep the input, request context, observed response and the specific reason it remains unresolved. A useful note explains what further permitted observation would distinguish the competing explanations. If that observation is outside the current scope or request budget, say so. Do not replace an unfinished comparison with a confident finding label merely to empty the review queue.
For the fictional exercise above, an item could say: “The candidate returned the same status as the missing-path baseline, but a different body sample; the account context has not yet been compared.” This is a record of uncertainty, not a verified vulnerability. It preserves a bounded next question for a later authorized review.
How should a pass with no displayed results be described?
Describe the selected inputs and conditions: which candidate set was used, which request template and identity were in scope, which classification settings were applied and whether the pass completed. Keep tool warnings and interrupted work visible. The record should explain what was attempted before drawing a conclusion from the displayed output.
A careful review statement might say that no candidate was retained under the recorded conditions. It should not claim that every possible path, account or application state was covered. Compare representative baseline responses and review permitted samples when the classification rule itself is uncertain. Preserve what could not be checked rather than silently broadening the conclusion.
What makes a comparison reproducible enough to review?
Record the installed FFUF version, candidate-set revision, target state, request template, relevant configuration and approved workload. Keep those details beside the disposition log and original output. A screenshot of the final rows alone leaves the reviewer to guess which inputs and classification choices produced them. The goal is to let another authorized reader understand the work without requiring an immediate rerun.
When a setting changes, explain why and preserve the previous baseline. The official FFUF repository and help document available controls; confirm behavior against the version actually installed. Keep illustrative counts from this article separate from your own measurements. A comparison is most useful when its evidence, limitations and next decision remain visible together.
Before the next FFUF comparison: Save the baseline request and its expected response, identify the one variable you intend to change and write the permitted request ceiling into the record. Leave room for validation rather than spending the whole allowance on new candidates. After the pass, reconcile actual workload with the plan and mark any interrupted work. Give each retained candidate a disposition or a specific unresolved question. This produces a reviewable handoff even when the next action is to pause, obtain missing context or revisit a classification choice instead of extending the wordlist.