FFUF Wordlist Tuning: common.txt vs Raft in 5 Steps

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.txt before 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 -h and any existing ffufrc. 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.json

The 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.json

If 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.json

Compare 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.

• -fs filters response size; -fw filters word count; -fr filters 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 -ac adds 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.