Why an exposed .env is a catastrophe (and how to fix it in a minute)
One file, one request, and an attacker holds the keys to your database and your payment gateway. Why it happens, and how to close it for good.
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
- Never serve the project root. Your webroot is
public/ordist/, not the whole repository. - Block it at the server level — in nginx,
location ~ /\.env { deny all; }. - Rotate every key that was ever exposed. If it leaked, it is compromised, even if it was only for five minutes.
It rarely travels alone
An exposed .env is usually a symptom of one deploy habit — shipping the whole project folder to the server — and that same habit exposes its cousins: a public .git directory carrying your entire history (including the keys you thought you'd deleted), stray config files, forgotten backups. If the .env was reachable, check for those too.
It's also not the only route your secrets take into the open. A key hardcoded into your frontend is published to every visitor and found by scrapers within hours — a different path to the same disaster. Both sit near the top of the complete security checklist for AI-built sites, because AI-generated deploys hit both constantly.
Checking whether your .env — or its cousins — is out there takes a second. Not checking can cost you everything. Run the check.
See what your site exposes
Run a free audit and get concrete issues in half a minute — no signup.
Check my websiteKeep reading
The complete security checklist for AI-built sites (Lovable, Bolt, v0, Cursor)
An AI can ship a working app in an afternoon — and leave a dozen doors unlocked. This is the full checklist I run against AI-built sites, in the order the findings actually bite.
July 19, 2026
One website audit or a dozen browser tabs? All-in-one vs single-purpose scanners
There's a great free tool for each of security headers, SSL, DNS, speed, SEO and cookies. Running all of them, reconciling the results, and knowing what actually matters is the real work. The case for a single scan.
July 19, 2026