How to Fix Exposed .env Files Before Hackers Find Them

Your .env file contains your database password, API keys, and secrets. Bots scan for it constantly. Here is how to check if yours is exposed and fix it in 5 steps.

Why .env Files Get Exposed

Every web application has secrets. Database passwords, API keys, payment tokens, email credentials. Developers store these in .env files to keep them out of source code. The problem is that an exposed env file is one of the most common security failures on the modern web, and it happens more often than you think.

If you use AI coding tools like Cursor, Lovable, or Bolt, you should pay extra attention. These tools are excellent at generating functional code fast, but they do not always handle secrets correctly. Some scaffold projects without a proper .gitignore. Others commit .env files directly into the repository. A few even place secrets in client-side code where they become visible to anyone who opens the browser devtools.

The three most common ways .env files get leaked:

• Committed to a public repo. AI tools generate a project, you push to GitHub, and the .env file goes with it. Even if you delete it later, the file lives in git history forever.
• Served by the web server. Misconfigured deployments can accidentally serve dotfiles as static assets. Visit yoursite.com/.env and the secrets are right there.
• Wrong .gitignore configuration. A missing entry, a typo, or an AI-generated .gitignore that does not cover all your environment files means secrets slip through.

What Attackers Can Do With Your .env

A leaked .env file is not just an embarrassment. It is the keys to your entire infrastructure. Here is what an attacker can do with the secrets inside:

• Database takeover. Your DATABASE_URL or SUPABASE_SERVICE_ROLE_KEY gives full read and write access to every row in your database.
• API abuse. Stolen OpenAI, Anthropic, or Stripe keys let attackers run up massive bills on your account. A single leaked AI API key can generate thousands of dollars in charges overnight.
• Billing fraud. Payment provider secrets like Stripe secret keys let attackers issue refunds, create fake subscriptions, or redirect payouts.
• Account impersonation. With your email provider credentials, attackers can send phishing emails from your domain, destroying your sender reputation.
• Lateral movement. One leaked secret often leads to others. A database connection string might reveal internal network addresses. An AWS key might give access to S3 buckets containing backups with even more credentials.

How to Check If Your .env Is Exposed

Before you can fix the problem, you need to know if you have one. Here are two ways to check.

Manual Check

Open your browser and try accessing these URLs on your live site:

https://yoursite.com/.env
https://yoursite.com/.env.local
https://yoursite.com/.env.production
https://yoursite.com/.env.backup

If any of these return content instead of a 404 error, your secrets are publicly accessible right now. Also check your git history:

git log --all --full-history -- .env .env.local .env.production

Automated Scan with UNPWNED

Manual checks only cover the obvious cases. UNPWNED runs a security scan that tests for exposed .env files along with dozens of other misconfigurations, including leaked source maps, open admin panels, missing security headers, and more. It takes less than 60 seconds.

How to Fix It: 5 Concrete Steps

If you have discovered an exposed env file or leaked environment variables, act immediately. Every minute the secrets are public, the risk of exploitation grows.

1. Rotate Every Compromised Secret

Do this first. Before fixing the leak, assume every key in the exposed file has been copied. Go to each service provider and regenerate the credentials. This includes database passwords, API keys, JWT secrets, and payment provider tokens. Do not skip any of them.

2. Remove the File from Git History

Deleting the file and committing the removal is not enough. Use git filter-repo or BFG Repo-Cleaner to purge the file from every commit:

# Install git filter-repo
brew install git-filter-repo

# Remove .env from entire git history
git filter-repo --path .env --invert-paths

# Force push the cleaned history
git push origin --force --all

3. Fix Your .gitignore

Make sure your .gitignore covers all environment file variations:

.env
.env.*
.env.local
.env.development
.env.production
.env.backup
!.env.example

4. Block Dotfiles in Your Web Server

Configure your hosting platform to deny access to all dotfiles. For Nginx:

location ~ /\. {
    deny all;
    return 404;
}

5. Move Secrets to Your Platform's Environment Manager

Stop relying on .envfiles in production entirely. Use your hosting platform's built-in secret management. Vercel, Netlify, and Railway all have encrypted environment variable storage. For local development, pull production values from the platform CLI:

# Pull env vars from Vercel to local .env.local
vercel env pull .env.local

Prevention Checklist

• Verify .gitignore includes .env* before your first commit
• Never use NEXT_PUBLIC_ prefix for secrets that should stay server-side
• Audit AI-generated code for hardcoded secrets before committing
• Set up a pre-commit hook that blocks .env files from being staged
• Use .env.example with placeholder values for documentation, never real credentials
• Enable GitHub secret scanning on your repositories
• Run an UNPWNED security scan after every production deployment

Do Not Wait for a Breach

Attackers run automated bots that continuously scan the internet for exposed env files. They check common paths like /.env, scrape GitHub for freshly committed secrets, and exploit leaked environment variables within minutes of discovery.

UNPWNED scans your site for exposed .env files, leaked source maps, open admin panels, missing security headers, and dozens of other vulnerabilities. One scan takes less than a minute. Fix the problems before someone else finds them.

No signup required. Get your security report in 60 seconds.