Deploys often copy more than intended into the web root. Three files cause most of the damage when they are publicly readable.

1. Test your own domain

From a terminal, using your own site:

curl -s -o /dev/null -w "%{http_code}\n" https://example.com/.git/HEAD curl -s -o /dev/null -w "%{http_code}\n" https://example.com/.env curl -s -o /dev/null -w "%{http_code}\n" https://example.com/backup.zip

You want 403 or 404. A 200 means the file is being served. Also beware of a catch-all that returns 200 with your homepage for every path: compare the body, not just the status.

2. Fix at the server, not by deleting once

  • nginx: location ~ /\.(?!well-known) { deny all; }
  • Apache: RedirectMatch 404 /\.git or <FilesMatch "^\."> with Require all denied
  • Better: deploy only a build output directory, never the repo root.

3. Assume exposure means compromise

If .env or a .git directory was reachable, rotate every key, token and database password it held. Deleting the file afterwards does not un-leak what was already fetched. Check server logs for earlier requests to those paths.

4. Make it a habit

Run the check after every deploy and when you change hosting or CDN settings, since a config change can quietly reopen a path you closed. One-off checks go stale; repeating them is what keeps the result true.