Exposed sensitive files (.env, .git, backups)

Files a deploy should never publish — .env, .git, database dumps — asked for by address and confirmed by what came back. Each one hands over credentials or source code.

• Help center

When a site is deployed by copying a working folder to the server, files that were never meant for visitors tend to travel with it: the .env with database passwords and API keys, the .git directory with the full source history, a backup.zip made before a risky change, a forgotten phpinfo.php. Bots request these addresses on every domain they find, so one that answers is usually discovered within hours.

How SiteScan checks

The scan requests a fixed list — /.env, /.git/config, /.git/HEAD, /server-status, /phpinfo.php, /.DS_Store, /backup.sql, /backup.zip, /backup.tar.gz, plus /wp-config.php.bak on WordPress — and reads at most 8 KB of each. A path only counts when the answer is a 2xx, not an HTML page, and the content proves it: known variable names in .env, a [core] section in Git config, zip or gzip magic bytes in an archive. A site that answers everything with its homepage is not flagged. Any hit turns the row red and lists the paths.

How to fix it

Delete the file, then treat its contents as leaked and rotate every password and key in it. Deny dot-files at the server, e.g. location ~ /\.(?!well-known) { deny all; } in nginx, and deploy a build artefact rather than a working copy. See also directory listing.