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 /\.gitor<FilesMatch "^\.">withRequire 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.
Top comments (0)