Exposed .env Files: The #1 Vibe Coding Mistake

The short version

A .env file stores sensitive configuration: API keys, database URLs, authentication secrets, payment provider keys. It's meant to stay on your server, never accessible to the public. But misconfigured deployments expose it to anyone who knows to check yourdomain.com/.env.

This is classified under CWE-538: Insertion of Sensitive Information into Externally-Accessible File and falls under the OWASP Sensitive Data Exposure category.

What's typically in a .env file

DATABASE_URL=postgresql://user:password@host:5432/mydb
STRIPE_SECRET_KEY=sk_live_abc123...
SUPABASE_SERVICE_ROLE_KEY=eyJhbGciOi...
RESEND_API_KEY=re_abc123...
JWT_SECRET=supersecretkey123

Every one of these is a skeleton key. With your DATABASE_URL, someone connects directly to your database. With your STRIPE_SECRET_KEY, they can issue refunds, view customer data, or create charges. With your SUPABASE_SERVICE_ROLE_KEY, they bypass all Row Level Security and have full database access.

How it gets exposed

Deploying to a static file server. If your .env file is in the same directory as your public HTML/JS files and your server serves all files in that directory, .env is publicly accessible.

Forgetting .gitignore. If .env gets committed to a public GitHub repo, it's game over. Bots scan GitHub constantly for leaked credentials. Even if you delete the file later, it's still in the git history.

Docker builds. Copying your entire project directory into a Docker image (including .env) and serving it with a web server can expose the file.

Framework misconfiguration. Some frameworks serve static files from the project root by default. If .env is at the root, it might be served as a static file.

How to prevent it

1. Add .env to .gitignore. This should be the first thing you do in any project:

# .gitignore
.env
.env.local
.env.production

2. Block access at the server level. Configure your web server to deny requests for dotfiles:

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

3. Use your platform's environment variables. Vercel, Netlify, Fly.io, Railway, and every major hosting platform lets you set environment variables in their dashboard. Use that instead of deploying a .env file.

4. Use .env.example for documentation. Create a .env.example file with placeholder values that you commit to the repo. This documents what variables are needed without exposing real values:

DATABASE_URL=postgresql://user:password@localhost:5432/mydb
STRIPE_SECRET_KEY=sk_test_...

5. Check before deploying. Run ls -la in your deployment directory. If .env is there, something is wrong.

What to do if you've been exposed

1. Rotate every key immediately. Every API key, every password, every secret in that file needs to be changed. Not tomorrow. Now.
2. Check for unauthorized access. Look at your Stripe dashboard, database logs, email provider activity, and cloud provider audit logs.
3. Check git history. If .env was ever committed, even if deleted later, it's still in the history. Use a tool like git-filter-repo to remove it from history, or rotate the keys (which is simpler and more reliable).
4. Set up monitoring. Services like GitGuardian scan repos for leaked secrets and alert you.

The vibe coding problem

When you generate a project with AI coding tools, the .env file is right there in the project. The AI often fills it with real-looking placeholder keys. You replace them with real keys. Then you deploy the whole directory. If your hosting serves static files from the project root, your secrets are public.

Always check: can I access /.env on my deployed site? If you get anything other than a 404, fix it immediately.

Check your site

Want to know if your site has this issue? Scan it now and find out in 60 seconds.