Why .env Files Get Exposed (and How to Tell If Yours Is)

An exposed .env file is one of the most damaging findings our Vulnerability Scanner can flag. It typically contains your database password, API keys, and signing secrets — all in plain text, all sitting on a public URL anyone in the world can request. Here's how it happens and how to fix it in under five minutes.

What's in a .env File?

.env files are the standard way modern web apps (Node, Laravel, Django, Rails, etc.) store environment-specific configuration. A typical .env looks like this:

DB_PASSWORD=Sup3rS3cret!
STRIPE_SECRET_KEY=sk_live_xxxxxxxxxxxxxx
JWT_SECRET=...
SMTP_PASSWORD=...
AWS_ACCESS_KEY=...

None of this should ever leave your server. If an attacker gets your .env, they have:

• Direct access to your database
• The ability to charge customers via your Stripe account
• The ability to forge user sessions (JWT secret)
• The ability to send email as your domain (SMTP creds)
• Full AWS account access

How Does It End Up Public?

The most common cause is misconfigured web servers. Frameworks like Laravel and Node.js expect the .env to sit one level above the public web root. But if a developer:

• Uploads the entire project folder to /var/www/html/ directly
• Sets the document root to the project root instead of the /public subfolder
• Or hosts on a shared host that doesn't enforce file-permission boundaries

...the .env ends up directly accessible at https://yourcompany.com/.env. Attackers run automated scanners across millions of sites every day looking for exactly this URL.

How to Tell If Yours Is Exposed (10 Seconds)

Open a browser and go to https://yourcompany.com/.env. If you see your environment variables, you have a problem. If you see a 404 or a redirect to your homepage, you're probably fine — but our scanner does a deeper check that verifies content type and signatures (so a SPA fallback returning 200 doesn't get false-flagged).

The Fix (5 Minutes)

Option 1: Move .env Above the Web Root

The cleanest fix. Your project structure should look like:

/var/www/yourapp/
.env ← here, NOT public
/public/ ← this is what the web server serves
index.php
/assets/

Set your web server's document root to the public subfolder.

Option 2: Block .env at the Web Server

If restructuring isn't an option (legacy app, shared hosting), block the file via web server config.

Apache (.htaccess):


Require all denied


Nginx:

location ~ /\. {
deny all;
}

This blocks every dotfile (.env, .git, .DS_Store, etc.), which is what you want.

Option 3: Use a Cloudflare Rule

If you have Cloudflare in front of your site, create a Firewall Rule: "URI Path contains /.env → Block." This is fast to deploy and works regardless of your server config.

If It WAS Exposed — Rotate Everything

If you confirm your .env was publicly accessible, assume it was scraped. Automated scanners harvest these by the millions. You need to:

1. Block public access to the file (above)
2. Rotate every credential in it — database password, API keys, JWT secret, SMTP password, every single one
3. Check your services for unauthorized usage (AWS billing, Stripe charges, weird database queries)
4. If credentials were in there for more than a week, consider this a security incident and notify your customers per breach laws

Other Sensitive Files to Check

Our scanner checks for these too. Block them all:

• /.git/config — full source code disclosure
• /.DS_Store — directory listing leak (Mac files)
• /wp-config.php.bak — WordPress credentials
• /backup.sql, /dump.sql — full database dumps
• /phpinfo.php — server config disclosure
• /.htaccess visible — server config disclosure

Need Help?

DME Computer Services performs hardening audits as scoped project work alongside your managed IT plan. We'll find exposed files, broken file permissions, and the dozens of other small misconfigurations that add up to real risk. Call 402-650-8407 or request a free 30-minute consult.

Related reading:

• WordPress Security Hardening Checklist
• Content Security Policy in 10 Minutes