Feroxbuster, Gobuster, and DIRB: A Practical Speed Comparison

Welcome back!

Before you can exploit anything on a web app, you usually need to find it first. A lot of what actually matters on a target — admin login pages, leftover backup files, forgotten API endpoints, config files someone forgot to remove — never shows up in a link on the homepage. Content discovery is how you go looking for that stuff instead of hoping it’s handed to you.

The tooling for this has gone through a few generations. DIRB was the long-time default. Gobuster came along and pushed things faster with a leaner Go-based implementation. The newer contender is Feroxbuster — written in Rust, built around recursion, and marketed as the next step up in speed.

In this walkthrough, we’ll explore Feroxbuster and compare it with traditional directory brute-forcing tools to see how it stacks up.

What Feroxbuster Is Actually Built For

A few things define how it behaves:

• Speed — it leans on Rust’s concurrency model to fire off requests in parallel rather than working through a wordlist sequentially
• A CLI that doesn’t fight you — the flags are readable and the defaults are sane, so you’re not fighting the tool’s syntax before you’ve even scanned anything
• Recursion by default — find a subdirectory, it automatically scans that too, no re-running the command yourself
• Filtering that thinks a little — it tries to cut down on noisy false positives instead of just dumping every response back at you
• Room to tune it — plenty of flags for adjusting threads, wordlists, and scan behavior once you outgrow the defaults

Step 1: Installation

On Kali, it’s already in the repos:

sudo apt install feroxbuster -y

Worth confirming it’s actually working before moving on — -h prints the full option list, which doubles as a fast way to see everything the tool can do.

Step 2: Basic Directory Brute-forcing

For this test, I’m scanning a local DVWA instance running in Docker — a safe, legal target instead of pointing these tools at a live site. Running a scan is just as simple. Point it at a target with -u:

feroxbuster -u http://127.0.0.1:8080

By default, Feroxbuster reaches for raft-medium-directories.txt — interestingly, from its own bundled copy of the wordlist rather than pulling it from SecLists, even with SecLists installed alongside it. The scan behavior itself lines up with what you’d expect from DIRB: status codes and discovered paths printed as it goes.

Step 3: Comparison with Gobuster and DIRB

The Step 2 scan already showed Feroxbuster working well on its own — but the real test is putting it head-to-head against the tools it’s meant to replace, using the same target and the same wordlist across all three so the comparison’s actually fair.

For Feroxbuster:

time feroxbuster -u http://127.0.0.1:8080 -w /usr/share/wordlists/dirb/common.txt -t 50 -q --no-recursion

A quick rundown of what each flag’s doing:

• -w — points it at DIRB’s own common.txt wordlist instead of the raft-medium list it used by default in Step 2. Keeping the wordlist identical across all three tools is what makes this a real comparison rather than three different tests.
• -t 50 — fires 50 requests at once instead of working through the list one at a time.
• -q — drops the banner and live progress bar, leaving just the results.
• --no-recursion — switched off deliberately here. Gobuster and DIRB don’t recurse the same way Feroxbuster does, so leaving recursion on would make the timing comparison meaningless.

Feroxbuster finished in 5.04 seconds.

Same test, now with Gobuster. It doesn’t recurse by default, so no extra flag’s needed here.

time gobuster dir -u http://127.0.0.1:8080 -w /usr/share/wordlists/dirb/common.txt -t 50 -q

Gobuster came in at 5.37 seconds. Slower than Feroxbuster this time, flipping the article’s original result, where Gobuster had actually edged out Feroxbuster.

DIRB’s turn. It’s single-threaded by default and recurses automatically, both of which would badly skew a timing comparison, so recursion gets disabled the same way, with -r:

time dirb http://127.0.0.1:8080 /usr/share/wordlists/dirb/common.txt -r

Executed in 1.18 seconds.

Summary

The result nobody would’ve predicted going in: DIRB won, and it wasn’t close. Not because it’s a better tool, but because the test conditions exposed something the source article never controlled for. Multi-threading only pays off when there’s something worth parallelizing against, and on a live remote target, that something is network latency. Strip the network out entirely by scanning localhost, and DIRB’s single-threaded design stops being a liability. There’s nothing left for 50 concurrent threads to outrun.

Feroxbuster and Gobuster, meanwhile, landed close enough to call it a tie. If you’re already using one, “it’s faster” isn’t a real reason to switch to the other. The actual lesson here isn’t about which tool wins. It’s that the environment you test in can matter more than the tool you’re testing.

Stay curious!