Is Your .env File Public? How to Find Out Right Now

Your .env file might be public right now. Not because you made an obvious mistake — because there are four different ways it can end up exposed, and most developers don't know about all of them.

This is a discovery guide. The existing env file fix guide covers the remediation process in detail. This post focuses on the part that comes before: figuring out whether you have a problem, and where to look.

We've scanned thousands of repositories. Exposed environment variables are the single most common critical finding. Let's check yours.

The Four Ways Your .env Gets Exposed

Before checking, understand the attack surface. Your env file can be public in four distinct ways:

Committed to git — The file is in your git history. Even if you deleted it from the current branch, it exists in past commits.
Publicly accessible on your server — Your web server serves .env as a static file at https://yourdomain.com/.env.
NEXT_PUBLIC_ prefix on secrets — In Next.js, variables with this prefix are bundled into client JavaScript and visible in the browser.
Leaked into application logs — Your app logs environment variables during startup or error reporting, and those logs are accessible.

Check all four. Finding one doesn't mean the others are clean.

Check 1: Is Your .env in Git History?

This is the most common exposure. A developer hardcodes a value to test something, commits it, then deletes the file and thinks the problem is gone. The commit history disagrees.

# Check if .env was ever committed
git log --all --full-history -- .env
git log --all --full-history -- .env.local
git log --all --full-history -- .env.production
 
# If you get output from any of these, the file is in your history

If you get output, your credentials are exposed. The file might not be on the current branch, but anyone who can access the repository can retrieve it from history.

To see what was in the file at any commit:

# Replace COMMIT_HASH with the hash from git log output
git show COMMIT_HASH:.env

What to do if you find it: Rotate every credential in that file immediately. Then read the env file fix guide for the full history rewrite process using git filter-repo.

Check 2: Is Your .env Directly Accessible on Your Server?

Some deployment configurations — particularly misconfigured nginx or Apache setups, or static file servers — will serve .env as a plain text file if it exists in the web root.

Check directly:

# Replace with your actual domain
curl -s https://yourdomain.com/.env | head -5
curl -s https://yourdomain.com/.env.local | head -5
curl -s https://yourdomain.com/.env.production | head -5

If you see environment variable content (anything starting with VAR_NAME=), your file is publicly accessible. That's a critical exposure — treat it as a breach.

You can also use our free env check tool to scan your deployed URL for exposed configuration files.

Google's index might already have cached your file. Search for site:yourdomain.com filetype:env to check.

Check 3: Are Your Secrets in NEXT_PUBLIC_ Variables?

In Next.js, any environment variable prefixed with NEXT_PUBLIC_ is bundled into the client-side JavaScript. It's visible to anyone who opens your app, opens DevTools, and searches the source.

Check your current env files:

# List all NEXT_PUBLIC_ variables in your .env files
grep -r "NEXT_PUBLIC_" .env* 2>/dev/null

Then audit each one. Ask: is this value safe to be public?

# BAD: secret key with NEXT_PUBLIC_ prefix
NEXT_PUBLIC_STRIPE_SECRET_KEY=sk_live_abc123  # anyone can see this
 
# BAD: service role key with NEXT_PUBLIC_ prefix
NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY=eyJ...  # bypasses all RLS
 
# GOOD: anon key — designed to be public, restricted by RLS
NEXT_PUBLIC_SUPABASE_ANON_KEY=eyJ...
 
# GOOD: public analytics key — designed to be public
NEXT_PUBLIC_POSTHOG_KEY=phc_...

The rule: NEXT_PUBLIC_ is for values the browser is allowed to know. Anything that grants elevated access to a backend service — Stripe secret key, Supabase service role key, API keys for server-to-server calls — must never have the prefix.

To verify what's actually in your built JavaScript bundle:

# Build your app and search the output
npm run build
grep -r "sk_live" .next/static/ 2>/dev/null
grep -r "service_role" .next/static/ 2>/dev/null

If you find secret-looking values in .next/static/, they're in your client bundle and therefore visible to your users.

Check 4: Are Secrets in Your Application Logs?

Some frameworks and error tracking tools log environment variables automatically. Others log them because of a startup debug message that looked harmless in development.

# Common patterns that accidentally log secrets
console.log("Config:", process.env)  # logs ALL env vars
console.log("Starting with", { dbUrl: process.env.DATABASE_URL }) # logs one

Search your codebase:

# Find potential secret logging in source
grep -r "process\.env\." src/ --include="*.ts" --include="*.tsx" | grep -i "log\|console\|sentry\|debug"

Also check your error tracking service (Sentry, Datadog, etc.) for any events that contain environment variable values. Error tracking tools sometimes capture the full process environment when an unhandled exception occurs.

Quick Discovery Checklist

Run through all four checks:

# 1. Git history
git log --all --full-history -- .env
git log --all --full-history -- .env.local
git log --all --full-history -- .env.production
 
# 2. Server accessibility
curl -s https://YOUR_DOMAIN/.env | head -3
 
# 3. NEXT_PUBLIC_ secrets
grep -r "NEXT_PUBLIC_.*SECRET\|NEXT_PUBLIC_.*KEY\|NEXT_PUBLIC_.*TOKEN" .env*
 
# 4. Source code logging
grep -rn "console.log.*process.env\|logger.*process.env" src/

If any check returns results, you have a problem. The order of urgency:

Server directly accessible — Treat as active breach. Rotate immediately.
In git history on a public repo — Treat as active breach. Rotate immediately.
NEXT_PUBLIC_ secret — Rotate and redeploy. Your build has been exposing it.
In git history on a private repo — Rotate and clean history. Lower urgency than public, but still real risk.

Scan Your Full Repo for Secrets

Manual checks find known patterns. A full scan finds patterns you didn't think to look for — API keys in test files, credentials in config fixtures, tokens in environment-specific files you forgot about.

Data Hogo's env check tool scans your deployed URL for exposed configuration files. The full repo scan covers secrets across your entire codebase — not just .env files, but anywhere a credential might be hiding.

Check your env configuration free →

For the full process of fixing what you find — rotating credentials, rewriting git history, and preventing future exposure — read the complete env file fix guide.

Prevent Future Exposure

Once you've confirmed your current state, set up these three protections:

1. Verify .gitignore

# Confirm these are in .gitignore
cat .gitignore | grep -E "\.env"
 
# Should see entries like:
# .env
# .env.local
# .env*.local
# .env.production

2. Remove tracked .env files

# If .env is currently tracked (even if in .gitignore)
git rm --cached .env
git rm --cached .env.local
git commit -m "remove .env from tracking"

3. Add a pre-commit hook

# Install gitleaks to block commits containing secrets
brew install gitleaks  # macOS
 
# Add to .git/hooks/pre-commit
#!/bin/sh
gitleaks detect --staged --verbose

The pre-commit hook is the most reliable protection. It blocks the problem at the source, before the commit is made, before the push happens.

Frequently Asked Questions

How do I know if my .env file was committed to GitHub?

Run this command in your repo: git log --all --full-history -- .env. If you get any output, your .env was committed at some point. Even if you deleted it later, the file exists in your git history and anyone who clones the repo can access it. You need to rotate every credential in that file and then rewrite history with git filter-repo to remove it.

Can Google index my .env file?

Yes. If your .env file is publicly accessible on your web server — for example, at https://yourdomain.com/.env — search engines can index it. This happens when .env files are accidentally deployed to a web root without server-side protection. Check by visiting https://yourdomain.com/.env directly. If you see environment variable content instead of a 404, your file is exposed.

Is it enough to delete my .env file from GitHub?

No. Deleting a file from GitHub removes it from the current branch, but it stays in the git history. Anyone can access it with git checkout or by browsing GitHub's commit history. You need to rotate all credentials in the file AND rewrite git history using git filter-repo to permanently remove the file from all commits.

What should I do immediately if I find my .env is public?

Act in this order: (1) Rotate every credential in the file — don't wait, do it now. (2) Revoke the old credentials in each service's dashboard. (3) Check your service logs for suspicious activity. (4) Rewrite git history to remove the file. (5) Add .env to .gitignore and verify it's not tracked. Rotating credentials is the urgent step — history cleanup can follow.

How do I prevent my .env from being committed again?

Three layers: (1) Add .env, .env.local, .env.production to .gitignore. (2) Run git rm --cached .env if the file is currently tracked. (3) Add a pre-commit hook that blocks commits containing common secret patterns — gitleaks is the standard tool for this.

The discovery step is the one developers skip. They add .env to .gitignore going forward without checking whether the damage is already done. Run the checks above. It takes five minutes, and the results tell you exactly what you're dealing with.

Scan your repo for exposed secrets →