Skip to main content

Fix Guides

How to Fix an Exposed .env File

Block public access to secrets immediately — then rotate everything.

Quick fix

If your .env file is publicly accessible, block web access immediately (move it outside the document root or deny via server config), then rotate every secret it contained — database passwords, API keys, Stripe keys, JWT secrets. Assume they are compromised. Re-scan to confirm the path returns 403/404.

A publicly reachable .env file exposes database credentials, API keys and application secrets to anyone who guesses the URL. This is a critical finding. Blocking access is step one; rotating every exposed secret is non-negotiable — scanners and attackers may already have copied the file.

Check your website

See how your site handles how to fix an exposed .env file — free, no account needed.

Business impact

Exposed environment files are among the fastest paths to a full site compromise — database theft, payment fraud, email hijacking and ransomware. If this finding appears on your scan, treat it as an active incident: block access, rotate secrets, review access logs, and consider a professional security review.

Why this happens

The scanner flags "Exposed Environment File" when /.env (or variants like .env.local, .env.production) returns HTTP 200 with content matching environment-variable patterns (DB_PASSWORD=, API_KEY=, etc.). Common causes: deploying a Laravel/Node/PHP app with .env inside the web root; misconfigured nginx/Apache serving dotfiles; or a backup copy (.env.backup, .env.old) left in a public folder.

How to confirm the issue

Manually: visit https://yoursite.com/.env in a browser or run curl -I https://yoursite.com/.env. HTTP 200 with key=value content means it is exposed.

With Plexa Trust: look for "Exposed Environment File" (critical). After blocking access and rotating secrets, re-scan — the finding should clear.

Step-by-step fix

  1. Block web access to .env immediately — deny dotfiles in server config or move secrets outside the document root.

  2. List every secret in the file: DB credentials, API keys, mail passwords, JWT/session secrets, Stripe keys.

  3. Rotate all of them — assume attackers already copied the file.

  4. Delete any backup copies (.env.bak, .env.old, .env.backup) from public directories.

  5. Review server and application access logs for suspicious requests to /.env.

  6. Re-scan to confirm the path returns 403 or 404.

Platform-specific fixes

Apache (.htaccess)

  1. Add: <FilesMatch "^\.env"> Require all denied </FilesMatch>

  2. Or deny all dotfiles: <FilesMatch "^\."> Require all denied </FilesMatch>

  3. Reload Apache and verify /.env returns 403.

Nginx

  1. In your server block: location ~ /\. { deny all; return 404; }

  2. Test with nginx -t and reload.

  3. Ensure .env lives above the web root if possible (e.g. /var/www/.env with root at /var/www/public).

Laravel / PHP frameworks

  1. The .env file must be in the project root, not inside public/.

  2. Only public/ should be the web root — never the project root.

  3. If already exposed, rotate all secrets and check git history for committed .env files.

IONOS / shared hosting

  1. Place .env one level above public_html if your host allows.

  2. Add deny rules via .htaccess in the web root.

  3. Contact host support if dotfiles are still served despite rules.

After rotation

  1. Update database password in hosting panel and in your app config.

  2. Regenerate API keys in Stripe, SendGrid, AWS, etc.

  3. Invalidate JWT/session secrets (forces all users to re-login).

  4. Deploy updated config and verify the app still works.

How to verify the fix

  • Never commit .env to git — use .gitignore and .env.example with placeholder values.

  • Store production secrets outside the web root or in a secrets manager.

  • Block all dotfiles at the server level as defence in depth.

  • Re-scan with Plexa Trust and confirm all env-path findings clear.

Common mistakes

  • Blocking access but not rotating secrets — attackers may already have them.

  • Leaving .env.backup or .env.old in a public folder.

  • Putting the Laravel/Node project root as the web document root.

  • Assuming "nobody knows the URL" — scanners probe /.env automatically.

Frequently asked questions

How urgent is an exposed .env file?

Critical. Treat it as an active breach — block access and rotate every secret immediately.

Do I need to rotate secrets if nobody visited the URL?

Yes. Automated scanners probe /.env constantly. You cannot know if it was already downloaded.

Where should .env live?

Outside the web-accessible document root. For Laravel, that means project root with only public/ as web root.

What if .env was committed to git?

Rotate all secrets, remove from git history (git filter-repo/BFG), and treat the repo as compromised.

Will .htaccess block .env on Apache?

Yes, with a FilesMatch rule denying dotfiles. Verify with curl after deploying.

What secrets are usually in .env?

Database URLs/passwords, API keys (Stripe, mail, AWS), app keys, JWT secrets, OAuth client secrets.

Is .env.example safe to expose?

It should contain only placeholder values with no real secrets — safe to commit and optionally serve.

How do I confirm the fix?

curl -I https://yoursite.com/.env should return 403 or 404. Re-scan with Plexa Trust to clear the finding.

Think you've fixed it?

Run a free scan to verify the issue is resolved. Upgrade to Pro on Plexa Trust for the full audit, monitoring alerts, and score history.

Verify with a free scan

Upgrade to Pro for monitoring