Glossary
What is .env — what happens when an environment file leaks
.env gathers an app's secrets (DB credentials, API keys, encryption keys) in one file. Why it's the most dangerous file, what each leaked secret unlocks, where to place it, and how to protect it in git and via rotation — with a self-check.
.env is extremely handy and almost every modern framework uses it. But put it in the wrong place once and it's like pinning your keyring to the front door. 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.
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.
| Leaked value | What happens |
|---|---|
| DB credentials | read / alter / wipe data |
| External API keys | impersonation use, fraudulent billing |
Encryption key (e.g. Laravel APP_KEY, signing keys) | session forgery, impersonated login |
| OAuth secrets | takeover of linked apps |
Indeed, exposing .env is a classic incident. → The .env exposed to the whole world
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.
✗ Dangerous (app at the public root)
public_html/ ├─ .env ← readable! ├─ app/ └─ public/
✓ Safe (app outside, only public served)
app-root/ ├─ .env ← unreachable ├─ app/ └─ public_html/ → public/
How to protect it
Don't put it in a public directory
Keep the app outside the docroot; serve only public/. Concrete steps for shared hosting: this guide.
Don't commit it to git
Add .env* to .gitignore and share only a .env.example with empty values.
Rotate everything if it leaks
Not just the one confirmed key — replace every key that was in .env. Act as if all were seen.
Self-check regularly
Build the habit of checking that /.env can't be opened on your own site.
Self-check (only against domains you own)
# 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 -1Checking this on every deploy catches placement mistakes early.
Read next
FAQ
QCan I commit .env to git?
No. Add .env to .gitignore. Instead commit a .env.example with empty values to share which keys are needed.
QIf even one secret leaks from .env, what do I rotate?
Not just the one you confirmed — rotate every key that was in .env. Priority: external API / OAuth secrets → encryption keys → mail → DB. Act as if all were seen.
QHow do I check whether .env leaked?
Open https://yourdomain/.env in a browser. If the contents show, it's exposed (200 with a body = bad). If it's blocked (403/404) you're okay for now.