Feroxbuster Tutorial: 9 Safe Steps for Recursive Web Recon

Feroxbuster is a fast web-content discovery tool that uses a wordlist to request paths on a server and can recursively investigate directories it finds. This tutorial shows you how to install it, choose a small test list, limit scan traffic, interpret responses and verify the findings. The objective is not to collect the biggest pile of URLs; it is to understand exactly what you asked your own application to reveal.

Unlike a one-pass directory check, Feroxbuster can follow discovered directories and test paths beneath them. That is useful, but it can multiply HTTP requests and probe routes you never meant to touch. I treat recursion as a controlled exercise after establishing a harmless baseline, not as permission to explore everything an application exposes.

The examples use a disposable local web application on Kali Linux or Parrot OS. They are illustrative commands, not evidence that I personally ran this exact test. Your target, installed release, supported options and observed responses may differ. Always confirm the scope and the help text on your own machine.

Lab ingredient	Purpose	Safe starting choice
A web app you control	Known test target	Disposable local service
Small wordlist	Limits requests and noise	Five harmless names
Recorded boundaries	Prevents scope creep	One host and one port
Tool version and notes	Supports reproducibility	Installed help and observations

Key Takeaways

• Start with permission: use only an application you control or are explicitly allowed to assess.
• Separate the two workflows: perform a non-recursive baseline before allowing recursive discovery.
• Limit more than one setting: threads, request rate, concurrent scans and runtime constrain different things.
• Read the responses: a status code alone does not prove a weakness.
• Verify and document: preserve the scope, filters, evidence and limits of every result.

1. Define Your Feroxbuster Lab Scope

A Feroxbuster tutorial should start with a target you can name, control and restore. Write down the protocol, hostname, port, owner, allowed paths and test window. In VMware, check that the target guest is not exposed to an unrelated network through bridging or forwarding. One reachable web page does not prove that every service linked from it belongs to you.

I use http://127.0.0.1:8080 as an example of a disposable service listening on the same machine as the scanner. Loopback always points to the machine running the command. If the application runs in a separate Linux guest, substitute its actual private address and port. Never paste a public host into a command simply because it appeared in a tutorial.

Identify the routes that must stay out of scope

Exclude sign-out, password-reset, payment, upload and expensive report-generation endpoints from the beginner exercise. Feroxbuster sends real HTTP requests, and even GET handlers can have side effects in a badly designed application. Check whether unknown paths trigger redirects, authentication workflows or external calls. If a route could affect real users, it belongs in a different plan with explicit authorization.

Start with a single service, no authentication and no following unexpected redirects. A third-party identity provider or content-delivery host is not automatically included in the scope because your app references it. Write down these exclusions before choosing a wordlist.

HackersGhost Note:
For a useful lab exercise, the first question is where requests might go. A narrowly defined boundary teaches more than a dramatic output screen.

2. Install Feroxbuster on Kali Linux or Parrot OS

The official Kali Linux repositories provide a Feroxbuster package. On Kali, apt is a practical installation route. On Parrot OS, first confirm that the configured repositories contain the tool; not every Kali package instruction carries over unchanged. Use the installed program’s help to verify the available flags.

sudo apt update
sudo apt install feroxbuster
feroxbuster --version
feroxbuster --help

Use a trustworthy source. The official open-source project is maintained in the epi052/feroxbuster GitHub repository. Its documentation warns that an unrelated dot-com domain with a similar name is not an official download source. I would rather verify a package origin than execute an unknown installer in a security VM.

The Kali Linux homepage is a useful route into the distribution’s package and tool information. It verifies availability in Kali, not a successful installation on your own Parrot guest. If installation fails, investigate repository support or the maintainer’s documented distribution methods instead of quietly switching to an untrusted binary.

Check the options before scanning

Save the executable version and confirm that your release recognizes --no-recursion, --depth, --rate-limit, --scan-limit and --time-limit. A missing safety-related option is a reason to inspect the release, not an invitation to delete the option from a copied command.

feroxbuster --version
feroxbuster --help
cat /etc/os-release

For a disposable VM, a snapshot before package changes makes rollback easier. Keep a short note of the OS, tool version and wordlist used. You can then revisit the method without confusing a new version’s defaults with the earlier environment.

3. Make a Small Wordlist You Understand

A beginner Feroxbuster wordlist does not need thousands of guesses. Five predictable names let you inspect every request and see whether recursion or link extraction unexpectedly expands the workload. A tiny input is also easy to reproduce after changing one variable.

Create a private working directory and a simple text file. These commands only write local files; they do not contact a web server. An application that has none of these paths is still a valid negative control, provided you document what was expected.

umask 077
mkdir -p ~/ferox-lab
chmod 700 ~/ferox-lab
cd ~/ferox-lab
printf '%s\n' docs assets images status help > lab-paths.txt
cat lab-paths.txt

If you control the test application, deliberately provide a known /docs/ route. That gives you a positive control for later runs. When the expected path appears, you can distinguish a working discovery pipeline from a noisy list of guesses. An empty scan against an unknown application offers less information.

Avoid premature extension guessing

Directory enumeration checks candidate paths such as /docs. Extension guesses add alternatives such as /docs.txt or /docs.html, increasing the request count. Save extension discovery for a separate exercise once the relevant file pattern is known. A large wordlist multiplied by extensions can overload a small lab long before you learn anything useful.

Record the wordlist’s contents, filename and source. Do not publish application-specific internal names or private evidence in screenshots. The selected candidates are part of the methodology, not disposable details.

4. Run Your First Feroxbuster Command Without Recursion

The first Feroxbuster pass should be deliberately boring: one local host, five candidate names, low concurrency and an automatic stop. After substituting your owned lab URL, compare the output with the application’s access log. A request that cannot be explained is a reason to inspect the setup before widening it.

feroxbuster -u http://127.0.0.1:8080 \
  -w ./lab-paths.txt \
  -t 1 --scan-limit 1 --rate-limit 2 \
  --time-limit 2m --no-recursion \
  --dont-extract-links

-u supplies the URL and -w the wordlist. -t 1 uses one worker thread. --scan-limit 1 restricts concurrent scans, while --rate-limit 2 sets a request rate per directory scan, not a universal two-request global ceiling. The time limit ends the run after the given interval. The final switches disable recursion and link extraction for this baseline.

Watch the server as it runs. A redirect to an outside authentication host, sudden load spike or surprising number of requests deserves investigation. A 200 may be real content or a custom fallback page; a 301 or 302 points elsewhere; and a 403 is an access denial, not evidence of a bypass. Interpret all three in context.

For a single-pass reference, the Gobuster tutorial shows another way to test known path candidates. Feroxbuster differs when you deliberately enable recursive discovery and need to understand the extra request tree.

Gobuster Command: 7 Proven Techniques for Web Recon

Gobuster Command: 7 Proven Techniques for Web Recon

5. Enable Feroxbuster Recursion With a Shallow Limit

Once the baseline makes sense, Feroxbuster can demonstrate its distinctive behavior: it finds a directory and requests candidate paths beneath it. That is recursive content discovery. It does not understand business logic or magically decide which routes are harmless. It follows configured discovery rules and real HTTP responses.

Prepare a known nested route, such as /docs/help, on your disposable application. Keep the same tiny wordlist, low concurrency and time limit. Changing only the recursion setting makes it easier to see why the request log grows.

feroxbuster -u http://127.0.0.1:8080 \
  -w ./lab-paths.txt \
  -t 1 --scan-limit 1 --rate-limit 2 \
  --depth 2 --time-limit 2m \
  --dont-extract-links

--depth 2 puts a shallow ceiling on recursive exploration. According to the current CLI documentation, a depth of 0 means unlimited recursion, so zero is not a safe shorthand for “disable.” Use --no-recursion when recursion should be completely off. These are different modes, and the distinction matters.

Rate limits do not replace a scope boundary

The rate limit is defined per directory scan. Multiple concurrent directory scans can increase aggregate traffic, which is why the example also uses --scan-limit 1. Confirm the real request volume from your server log rather than treating a CLI flag as an absolute guarantee. If new paths lead toward logout, payments or external hosts, stop and revise the scope.

A recursive Feroxbuster run is useful when it answers a bounded question, such as whether known lab directories contain more known paths. It is not an invitation to expand into every location visible through a redirect.

HackersGhost Note:
Recursion multiplies opportunities to learn and opportunities to make a mess. Three well-explained paths beat a thousand lines whose origin nobody can reconstruct.

6. Filter Wildcards and False Positives

Some applications return a friendly 200 page for every nonexistent path. In that environment, Feroxbuster can report an impressive-looking list even when nothing meaningful was discovered. Other sites redirect nearly every request to a login page. Before applying filters, reproduce those behaviors with a single harmless request.

curl -i http://127.0.0.1:8080/this-lab-path-should-not-exist

Compare the response status, body and length with a known legitimate route. The tool supports filters by response size, word count, line count, status and similarity. If your own fallback responses are consistently 1234 bytes, for example, you could exclude that length. 1234 is an illustrative value, not a measured result from my lab. Replace it with real evidence from your application.

feroxbuster -u http://127.0.0.1:8080 \
  -w ./lab-paths.txt -t 1 --scan-limit 1 \
  --rate-limit 2 --time-limit 2m \
  --no-recursion --dont-extract-links \
  --filter-size 1234

A filter can also hide a genuine file that happens to match the excluded size. Keep the reason for each rule in your notes and check its effect against a known valid resource. Do not use --dont-filter reflexively: that option disables automatic wildcard-response filtering and may make the output noisier.

Read 403 and redirect responses carefully

A forbidden page may be protected exactly as intended. A redirect can be a canonical-path adjustment or an authentication requirement. Check the destination and the returned body before concluding anything. A found URL, an access denial and a confirmed security defect are three separate observations; reporting them as one finding misleads readers and developers.

7. Control Traffic, Exclusions and Output

A responsible Feroxbuster workflow combines multiple limits. A small wordlist reduces candidates, one thread lowers concurrency, a scan limit restricts parallel directory scans, rate limiting slows requests, and a time limit provides an ending. Monitor the web-server log because no combination of flags proves that an application is immune to load or side effects.

The --dont-scan option can exclude named URLs or patterns when certain routes are outside the engagement. Check its syntax on your installed version. Exclusions are guardrails, not authorization: a scanner setting cannot make an impermissible request permissible.

Save output in your private lab directory so the result remains available for verification. The following example keeps recursion and link extraction disabled while writing to a local results file. It is not a command to run against production.

feroxbuster -u http://127.0.0.1:8080 \
  -w ./lab-paths.txt -t 1 --scan-limit 1 \
  --rate-limit 2 --time-limit 2m \
  --no-recursion --dont-extract-links \
  -o ferox-lab-results.txt

The file may contain internal route names, account identifiers or other information that belongs in a private evidence store. Use restrictive file permissions, and remember that permissions are not encryption. Do not sync real assessment data into a public folder or publish raw results for the sake of making a screenshot look technical.

Stop the run if the target starts returning sustained errors, if unrelated hosts appear, or if expected requests suddenly expand. The output is only useful when you can explain what generated it.

The FFUF tutorial approaches another part of controlled web fuzzing and response comparisons. It is a helpful reference when you need precise word substitutions rather than automatic traversal of directory trees.

FFUF Tutorial for Beginners: 9 Practical Fuzzing Examples

FFUF Tutorial for Beginners: 9 Practical Fuzzing Examples

8. Compare Feroxbuster With Gobuster and FFUF

Feroxbuster vs Gobuster is a workflow decision, not a popularity contest. Gobuster handles directory, DNS and virtual-host enumeration; Feroxbuster is a strong fit when recursive directory and file discovery is the actual task. Its recursion, scan depth and scheduling controls change the workload, so the same wordlist may lead to very different request patterns.

FFUF offers flexible fuzzing of selected parts of an HTTP request with detailed matching and filtering. Choose a simple single-pass process when you only want to check known candidates. Choose shallow recursion when you must inspect children of discovered directories. Use a more targeted fuzzing setup when the question concerns a particular parameter or HTTP request structure.

None of these programs performs an entire penetration test just because it finds an unlinked route. An exposed path may need access-control testing, configuration review or a developer explanation. A hidden path is not automatically a vulnerability, and a 403 is not automatically a successful exploit.

This Feroxbuster tutorial focuses on safe recursion and results verification. The Gobuster and FFUF articles already cover their own syntax and workflows, which is why this post does not repeat their beginner commands. Their differences make the three articles useful companions instead of competing versions of the same answer.

The OWASP Foundation homepage provides a starting point for broader web application testing guidance. Its testing methodology separates finding resources from demonstrating a security weakness. Keep that distinction in mind when moving from discovery to an actual security assessment.

Nikto Web Server Scanner: 7 Useful Checks for Beginners

Nikto Web Server Scanner: 7 Useful Checks for Beginners

9. Verify Findings and Write a Useful Report

An ethical Feroxbuster session ends when the observations are understandable. Revisit each unexpected result manually inside the authorized environment. Compare the returned status and content with the scan record and check for fallback behavior. If the server returns the same page for everything, classify the resulting noise accurately.

Record the target, owner, time window, tool version, wordlist, recursion setting, filters, exclusions, limits and result filename. For each interesting path, note what was observed, whether it was reproduced and what remains uncertain. A developer can act on a concise, verified finding; an unexplained list of URLs rarely helps.

If you discover an accidentally exposed file on your own server, restrict access or remove it, review server routing and assess whether any secrets were accessible. Rotate affected credentials if necessary and retest with the original method. Do not publish secret values or other people’s data as proof.

An empty scan only tells you that this particular collection of candidate paths produced no reportable results under the chosen settings. It cannot establish the absence of unlinked resources, hidden application states or authorization flaws. State that limitation plainly.

The five facts I would save for the next lab session

• Scope: the owner, host, port and permitted routes.
• Method: exact tool version, wordlist, options, limits and exclusions.
• Observed response: path, status, content behavior and any relevant redirect.
• Verification: what you manually confirmed and what may be a false positive.
• Action: a specific remediation or a clearly authorized follow-up.

This Feroxbuster report structure keeps the discovery step separate from the security conclusion. It also makes a retest fair: compare the same target, input and assumptions instead of celebrating a shorter output that might simply result from a new filter.

Common Feroxbuster Mistakes to Avoid

Starting with a huge public wordlist, excessive concurrency and unbounded recursion is a poor beginner combination. So is copying a command without checking whether its loopback address refers to the right VM. Another common mistake is counting every 200 response as a real discovery while a soft-404 page quietly answers every path.

Avoid broad scans when you have not excluded sensitive workflows. Do not assume --rate-limit is a global traffic guarantee, or that a 403 proves an access-control issue. Keep authentication details and internal routes out of screenshots and publicly shared output.

If you cannot explain where Feroxbuster will send its next requests, disable recursion and link extraction, reduce the wordlist and start again. A smaller successful exercise usually produces a better lesson than a large accidental one.

Feroxbuster Tutorial FAQ

Final Thoughts: Make One Safe Scan Explainable

The useful outcome of this Feroxbuster tutorial is a repeatable process: verify ownership, prepare a small wordlist, run a non-recursive baseline, enable shallow recursion only when justified, and check any surprising response manually. Record not just what appeared but what the test could not establish.

Start with a disposable application and a known /docs/ route. Run the low-rate first-pass command, compare the access log with the results, and change one setting at a time. That turns Feroxbuster from a busy terminal into an understandable ethical-hacking tool.