The files you forgot about are often the ones that cause trouble on your own website. Old backup copies, leftover installer scripts, test folders and unlinked admin pages can sit on your server for years without anyone noticing. Auditing your own site with dirbuster is one of the fastest ways to find them — but only if you run the scan well. A careless scan returns hundreds of hits, most of them meaningless, and you end up ignoring the results altogether.
Dirbuster is an OWASP directory and file brute-forcing tool built for legitimate security auditing. It requests a long list of common file and folder names from your own web server and reports which ones actually respond. The quality of that list — the wordlist — decides whether your audit is useful or just noise. These tips will help you choose better wordlists and cut false positives from your results.
Start With a Wordlist That Matches Your Own Stack
The biggest mistake in a directory scan is starting with the largest wordlist available. A mega-list with millions of entries takes hours, hammers your own server, and buries real findings under junk responses. Start small instead: run a short general list of a few thousand common names first, then move to a second list matched to your stack — WordPress names for a WordPress site, PHP and backup extensions for a custom PHP app. Targeted lists finish faster, and their hits are far more likely to matter. Over time, build a small custom list from your own findings — backup names and test pages you have actually found on your own projects.
Tune Extensions and Response Handling
Dirbuster lets you test file extensions alongside each word, and this setting matters more than most people realise. If your site runs on PHP, testing .php, .bak, .old and .zip alongside plain names catches backup copies such as config.php.bak that a plain scan misses. Add only the extensions your stack actually uses. Before the full scan, request a few nonsense paths on your own site and study the responses. If your site serves a friendly custom error page with a 200 status, the tool may report every guess as a hit. Knowing your baseline response first lets you filter those out later.
Spot the False Positives Before They Waste Your Time
False positives usually have a pattern. The classic sign is a run of hits that all return the same page size, the same title or the same redirect target — that is almost always a wildcard or catch-all response, not a set of real files. Another giveaway is a hit on a path you know you deleted: if the content served is your homepage or a generic error page, it is not a real file. Filter aggressively. Group results by response size and content, and set aside any group where dozens of different names return identical content.
Verify Every Hit by Hand
No scan result should go straight into a fix list without a human check. Open each remaining hit in a browser while logged out, exactly as a visitor would see it, and confirm that the file or folder really exists and contains what the scan suggests. A backup file holding only an error message is not a leak, and an admin panel that redirects to a login page is not an open door. It also stops panic deletions breaking your own site, since a test folder might still serve images your live pages use.
Turn Clean Results Into Fixes
Once your list contains only verified findings, the fixes are usually straightforward. Delete backup and installer files from the live server, restrict admin and staging folders by IP or password, and fix your deployment process so test files stop reaching production. Then run the same scan again with the same wordlist: a clean second run is the proof that the fixes worked. For a deeper look at the tool itself, visit dirbuster.com and read its documentation before your next audit.
