Exposed .env File? How to Check and Fix It Fast

If you built your app by prompting an AI tool, there's a real chance your secrets are already public. An exposed .env file is the most common — and most expensive — mistake in vibe-coded apps. A single leaked key can run up a five-figure cloud bill overnight or hand an attacker a direct line into your database. The scary part: most founders have no idea until it's too late.

Here's how to check in about five minutes.

How .env files get exposed

AI coding tools optimise for "make it work," not "keep it secret." So secrets leak in predictable ways:

• The .env file gets committed to git (and pushed to a public repo).
• API keys get hardcoded directly into frontend code.
• Server-only secrets get shipped to the browser bundle, where anyone can read them.
• Keys end up in public storage buckets or client-side config.

Any one of these means your "private" key is effectively published.

The 5-minute exposed .env check

Run through these quickly:

1. Check git history. Search your repo for .env, API_KEY, SECRET, sk_, Bearer. If any real values show up in commits, they're compromised — even if you deleted them later (git remembers).
2. Inspect your live bundle. Open your deployed site, open DevTools → Sources, and search for your keys. If you can find them in the browser, so can attackers.
3. Look at your repo visibility. Is it public? Was it ever? Public-for-five-minutes is enough for bots to have scraped it.
4. Review client config. Anything prefixed for the browser (e.g. NEXT_PUBLIC_, VITE_) is public by design — make sure no real secret is in there.

What to do if a key leaked

Don't panic — act in order:

1. Rotate the key immediately. Generate a new one and revoke the old one at the provider.
2. Check usage/billing for anything unexpected.
3. Purge it from git history (not just the latest commit).
4. Move it server-side so it never ships to the client again.

How an exposed .env file happens

• Keep all secrets in server-side environment variables, never in client code.
• Add .env to .gitignore before your first commit.
• Use publishable vs. secret keys correctly — only publishable keys belong in the browser.
• Add a secret-scanning step so leaks get caught automatically.

What an exposed .env file actually costs

This isn't theoretical. Bots constantly scan public repos for keys, and they find them within minutes of a push. The moment an exposed .env file goes public, attackers can spin up expensive cloud resources on your account, drain paid API credits, read or delete your database, and impersonate your app to your own users.

The bill arrives fast. Founders have woken up to five-figure cloud charges from a single leaked key used to mine crypto. Others have had entire user tables dumped and held for ransom. And because the key was yours, the provider holds you responsible.

The takeaway: treat any leaked secret as already abused. Rotate first, investigate second. A key that sat in a public repo for even ten minutes should be considered compromised — speed matters far more than certainty here.

Your secret-safety checklist

• No secrets anywhere in git history
• No real keys in the browser bundle
• .env is gitignored
• Only publishable keys client-side
• Leaked keys rotated and revoked

If you'd rather have an expert scan it for you, that's exactly what our free exposed secret scan does — we find what's leaked, rotate it, and lock your environment down.

Get a free secret scan →