What is .env — what happens when an environment file leaks

.env is extremely handy and almost every modern framework uses it. But put it in the wrong place once and every secret in it can be read by anyone. Here's what it is and how to protect it, from zero.

A bit more detail

Apps have "values that change per environment" and "values you don't want anyone to see": the DB password, external API keys, the key that encrypts sessions. Hard-code these into source and the secrets leak the moment you share the code.

So you collect them into one .env file and read them as "environment variables" from code. Next.js, Laravel, Rails, and many frameworks work this way.

The contents are plain text, one NAME=value per line (the values below are placeholders).

APP_ENV=production
DB_HOST=127.0.0.1
DB_PASSWORD=your-db-password-here
PAYMENT_API_KEY=your-payment-api-key-here

Keeping config outside the code was popularized by the web-app design guide "The Twelve-Factor App". Its test for whether config is properly separated is whether the codebase could be made open source at any moment without compromising any credentials. .env is a convenient container for that idea during development.

How it differs from similar things

Here are the things most often confused with .env. Only some of them are a safe place for secrets.

The fourth row is the one people miss. Next.js embeds the values of variables starting with NEXT_PUBLIC_, and Vite those starting with VITE_, into the JavaScript shipped to the browser at build time. Even if it lives in .env, a variable with one of these prefixes becomes public.

Why it's the "most dangerous file"

Because multiple keys sit in one file, a single exposure spreads damage fast. Listing "what each leaked value unlocks" makes the severity clear.

Indeed, exposing .env is a classic incident. → The .env exposed to the whole world

Real cases: exposed .env files being targeted

• A large-scale extortion operation (2024): a security company's research team reported activity that targeted 110,000 domains, collected .env files exposed on web servers, used the cloud credentials inside to take data, and demanded ransom. Over 90,000 variables were collected, about 7,000 of them for cloud services and about 1,500 for social media accounts. The cause was not a cloud-provider vulnerability but misconfiguration by the organizations that exposed their .env files
• Vercel (April 2026): unauthorized access to internal systems led to some customers' environment variables being read — those stored in the category whose values can be displayed again → full write-up
• Public repositories (a 2026 study): more than 540,000 credentials published on GitHub were still valid at the time of the study. Deleting the file or the history doesn't help unless the credential is revoked → full write-up

The first case shows that exposed .env files aren't found by people browsing — they're collected automatically and at scale. Don't assume a small site won't be found.

The typical leak = a placement mistake

The biggest cause is "putting the whole app in the public directory (docroot)". Where only public/ should be served, exposing its parent makes .env reachable too.

public_html/
├─ .env   ← readable!
├─ app/
└─ public/

app-root/
├─ .env   ← unreachable
├─ app/
└─ public_html/ → public/

Besides placement, it also leaks through these routes:

• Committing it to Git (instantly public in a public repo; visible to everyone with access in a private one)
• Leaving backups such as .env.bak or .env.old in the public directory
• Shipping a container image or a distribution zip with .env still inside
• Putting secrets in NEXT_PUBLIC_ / VITE_ variables, as described above

How to protect it

How to check your site and repository

# A 200 with a body means it's exposed. 403/404 is okay for now.
curl -sI https://yourdomain/.env | head -1
curl -sI https://yourdomain/.git/config | head -1

Check both the outside of the site and the inside of the repository.

1. For a site whose ownership you've verified, the site security audit checks /.env, /.env.local, /.env.bak and similar paths in one go
2. In the repository, run git log --all --oneline -- .env to see whether it was ever committed. If anything shows up, revoke the keys it contained
3. Paste config or code into the secret leak scanner to spot hardcoded API keys or private keys (it runs in your browser)
4. Review the list of NEXT_PUBLIC_ / VITE_ variables to make sure no secret ends up in the built JavaScript

Sources (primary)

• The Twelve-Factor App, "III. Config" — 12factor.net (store config in environment variables; the open-source litmus test)
• Next.js docs, "Environment Variables" — nextjs.org (NEXT_PUBLIC_ is inlined into JavaScript at build time; don't commit .env files)
• Vite docs, "Env Variables and Modes" — vite.dev (VITE_ variables are exposed to client code)
• Unit 42 (Palo Alto Networks), "Leaked Environment Variables Allow Large-Scale Extortion Operation in Cloud Environments" (August 15, 2024) — unit42.paloaltonetworks.com

Read next

• Incidents: The Laravel .env exposed to the world · Vercel environment variable exposure
• Defense: Keeping .env off the public web on shared hosting · Auditing secret files in public directories · Stopping secrets before commit
• Basics: What's dangerous about .env and API keys