Why an exposed .env is a catastrophe (and how to fix it in a minute)

Your .env file is the quiet centre of most applications. It holds the database connection, the API keys, the secret that signs your sessions. It is built to never leave the server. And it is still one of the most common serious findings I see.

How it happens

A "copy the whole directory to the server" deploy takes .env along with everything else. When the web server then serves static files from the project root, this is what you get:

GET /.env HTTP/1.1
Host: your-site.com

HTTP/1.1 200 OK
Content-Type: text/plain

DATABASE_URL=postgres://user:password@db:5432/app
STRIPE_SECRET_KEY=sk_live_...

One request, and an attacker has a connection to your production database and a live payment key.

Why it's worse than it looks

It isn't just that one file. With DATABASE_URL they read your data and delete it. With STRIPE_SECRET_KEY they see your customers and issue refunds. And because secrets get recycled across environments, one leak often unlocks staging and local too.

The fix

1. Never serve the project root. Your webroot is public/ or dist/, not the whole repository.
2. Block it at the server level — in nginx, location ~ /\.env { deny all; }.
3. Rotate every key that was ever exposed. If it leaked, it is compromised, even if it was only for five minutes.

Checking whether your .env is out there takes a second. Not checking can cost you everything.