The Files Your Website Must Never Serve

Why they go public

Mis-set document roots, deploy-the-whole-folder habits, and temporary debug files left behind.

One bad deploy can undo years of careful secret management.

Readers skimming exposed env files often stop at definitions. The part that prevents incidents is the verification step after the change - and the habit of re-checking after the next deploy that touches the same layer.

Stop the class

Deny rules at Nginx/Apache/CDN, fix the deploy layout, re-scan for the usual paths.

Also search the repo for accidental commits of .env - that is a different incident with the same outcome.

Common failure mode for exposed env files: staging looks fine, production still serves the old config because a CDN, load balancer, or second vhost was never updated. Always verify the hostname customers hit.

After a hit

If a secret was public, rotate it. Do not only 404 the path and hope nobody saved a copy.

Assume download happened. Rotation is the control.

If this section on exposed env files becomes a recurring ticket, automate the check. Manual one-offs rot; a post-deploy assertion or weekly grade keeps the control honest.

Config to copy

location ~ /\.(env|git|svn) { deny all; return 404; }

Paste carefully. Test on staging first if the setting can lock users out.

What to do this week

1. Add deny rules for .env, .git, backups at the edge.
2. Fix deploy layout so secrets never live in the web root.
3. Scan for public secret paths; rotate anything that was exposed.
4. Add a post-deploy check for the usual paths.

If the document root can serve it, someone will request it.

Run a free security grade on your domain · Pricing