Exposed files: when your website leaves the keys under the mat

The short version

What is actually at risk

Think of your website as a shop. The shop floor is public — that is your pages. But behind the counter there is a back office with the safe, the staff rota and the alarm codes. Exposed files are what happens when the back-office door is left open and the sign on the front says "staff only" but nothing actually stops anyone walking in.

The most dangerous files, in rough order of how bad it is if they leak:

• .env — the modern standard place to store secrets. Database password, email password, API keys for payments (Stripe, PayPal), cloud storage keys. A single readable .env file can hand an attacker your entire business in one download. We treat this as critical.
• .git — if your site was deployed from a code repository, the hidden .git folder may have come along for the ride. It contains the complete source code *and every previous version of it*, including passwords that were once in the code and later removed. Also critical.
• wp-config.php backups — WordPress keeps its database login in this file. Editors and hosting panels sometimes leave copies behind (wp-config.php.bak, wp-config.php~). The copy is readable even when the original is not.
• phpinfo.php — a diagnostic page developers create to see the server configuration, and then forget to delete. It reveals your exact PHP version, every installed module, file paths, and sometimes environment variables containing secrets. It is a map of your server for an attacker.
• Backup archives (backup.zip, site.tar.gz, db.sql) — a whole-site backup left in the web folder is a whole-site download for anyone who guesses the name. And they do guess: these names are in every scanner's list.
• .htpasswd — the password file for password-protected areas. Readable means crackable.
• .DS_Store — a harmless-looking file Macs create, which leaks the names of every file in the folder. Low risk on its own, but it tells an attacker exactly what else to look for.

Why "nobody knows the address" is not protection

The instinctive defence is: "but nobody knows that file is there." Unfortunately, they do not need to. Attackers run automated tools that request hundreds of common sensitive filenames from every website they can find — /.env, /.git/HEAD, /phpinfo.php, /backup.zip and so on — and record which ones answer. It costs them nothing and runs around the clock. If the file is reachable, it will be found; the only question is when.

This is why VigilScan checks these specific paths. We request them exactly as an attacker would, and we only flag a problem when the response is genuinely the sensitive file — not just a page that happens to return something.

How to check

VigilScan tests the most dangerous paths automatically and shows you exactly which address responded. You can also try it yourself: type yourdomain.com/.env or yourdomain.com/.git/HEAD into a browser. If you see anything other than a "not found" or "forbidden" page, you have a problem.

How to fix it

There are two parts: remove or move files that should not be in the web folder at all, and block access to the ones that must stay.

Remove: delete phpinfo.php, any backup archives, old config copies and .DS_Store files from your public web folder (public_html on cPanel). Backups belong somewhere not reachable by a browser — a folder *above* public_html, or off the server entirely.

Block: for files that have to exist (.env, .git, .htpasswd), deny web access with a few lines in your .htaccess file. On Apache or LiteSpeed hosting (which covers almost all cPanel hosting), add this to the .htaccess in your web root:

# Deny access to all dotfiles and sensitive files
<FilesMatch "^\.">
    Require all denied
</FilesMatch>
<FilesMatch "\.(env|ini|log|sql|bak|zip|tar|gz)$">
    Require all denied
</FilesMatch>
RedirectMatch 404 /\.git

Then test again — the addresses should now return a 403 or 404.

On WordPress specifically: make sure wp-config.php sits in the web root with no backup copies alongside it, delete readme.html and license.txt from the root (they advertise your version), and if your host offers it, move wp-config.php one level above public_html — WordPress will still find it there.

Directory listing, debug pages and installers

Three related problems we also check for on verified domains. Directory listing is when visiting a folder with no index page shows a list of every file in it — a free inventory for an attacker. Add Options -Indexes to .htaccess to switch it off. Debug mode is when your site shows detailed error pages with file paths and code snippets — turn it off in production (WP_DEBUG to false in WordPress, APP_DEBUG=false in Laravel). Leftover installers like /wp-admin/install.php, phpMyAdmin setup pages or Adminer should be deleted once setup is done; they are a well-known way in.

Common questions