The misunderstanding at the start
Many owners believe a file is only reachable if a link points to it. That is false, and it is the misunderstanding that costs the most in exposure terms. A web server serves everything in its public folder, to whoever asks for the right address. The link helps you find the page; it protects nothing.
Second misunderstanding: « nobody will guess that filename ». Nobody guesses, indeed. Bots do not guess, they work through lists. Those lists are public, maintained, and hold the few hundred names humans actually use: backup.zip, site.sql, config.old, .env, wp-config.php.bak. A brand-new website receives that kind of probing within hours of going live.
The recurring categories, by severity
1. Configuration files. They hold database credentials, and often API keys. The classic case is not the file itself, which servers usually know how to protect, but its renamed copy: .env.bak, config.php.old, wp-config.php.save. The extension changed, so the protection rule no longer applies, and the server serves it as plain text.
2. Backups and database exports. A .sql or .zip left after a migration holds the entire website, accounts and hashed passwords included. It is the most rewarding find for an attacker, and the most frequent one after a redesign.
3. The .git folder. Deploying a website by copying a working folder brings its full history along. A reachable .git folder allows the whole source code to be reconstructed, including deleted files and the credentials they contained before removal.
4. Logs and error files. They reveal absolute server paths, software versions and sometimes visitor data.
5. Directory listing. Not a file but a setting: when a folder has no index page, the server displays its contents. The attacker then has nothing left to guess, you handed over the table of contents.
The robots.txt trap
A common reflex is to write a line like Disallow: /private-admin/ in robots.txt so Google does not index the area. The intent is good, the effect is the opposite of the one sought.
robots.txt is a public file, readable by anyone at yourdomain.com/robots.txt. Writing the path of a sensitive area there amounts to publishing the address of your back door. Honest bots obey and stay away; the others find their roadmap, and those were exactly the ones you cared about.
The rule: robots.txt steers the indexing of public content. An area that must stay private is protected by a password or an IP filter, never by a line in a public file.
Check yours, with no tool
Open a tab and type these addresses one by one after your domain name. You should get a 404 error every time:
/.envand/.env.bak/backup.zip,/backup.sql,/dump.sql/.git/config/wp-config.php.bakif you run WordPress/uploads/or/files/, to see whether the folder listing appears
Anything answering something other than an error is to be removed from the server today, not renamed. Renaming moves the problem: the new name will end up on a list too. And if one of these files was exposed, treat the credentials it held as compromised: change them rather than hoping nobody looked.
The special case of automatic backups
There is one trap that manual checks almost always miss, because it does not come from human forgetfulness: backup plugins.
Most backup solutions for self-hosted websites write their archives into a subfolder of the site itself, for example /wp-content/backups/. That is convenient and logical from the plugin's point of view. The problem is that this folder sits in the public tree: every nightly backup drops a complete archive of the site, reachable by anyone who knows the path, and those paths are documented since the plugin is public.
The symptom is treacherous: you did nothing wrong, you followed the good advice to take backups, and you created a daily exposure that renews itself.
Three fixes, in order of robustness:
- Move backups out of the public folder. Most plugins let you choose a remote destination, at a storage provider or over file transfer. That is the right answer, and it also covers the case where the server burns down with its backups.
- Deny access to the folder through a server configuration rule, if backups must stay local.
- Check after every hosting change, because a migration often resets server rules without touching the content.
What our audit measures
The exposure and sensitive files category holds 8 checks. It tests a series of paths known to be sensitive, looks for an active directory listing, for a generator tag announcing your software version, for reachable admin and deployment paths, for an abandoned JavaScript library, for admin paths named in your robots.txt, and for technical error messages showing in the tested pages.
The limit is clear and stated: we test a finite list of common paths. A file with an unusual name, left in a subfolder nothing links to, will not be found by our audit. It will not be found by most bots either, but the absence of a finding is not proof of the absence of a file. The only exhaustive check remains listing the real contents of your public folder.