ShipGuardScan a site

Publicly Exposed .env File: Detection and Fix

Updated 2026-10-17

An exposed .env file usually means the web server is serving the project root instead of a build directory, or a deploy step copied dotfiles into the public folder.

Test without fooling yourself

Single-page apps often return index.html with HTTP 200 for every path. A 200 on /.env therefore proves nothing on its own — check that the body is actually KEY=value lines and not your HTML shell.

curl -s https://your-app.com/.env | head -c 300

Fix

Serve only the build output (dist/, build/, .next), deny dotfiles at the server or CDN, keep .env* in .gitignore, and move secrets into the host's environment settings. Rotate every value that was in the file.

Checklist

  • /.env and /.env.local return 404
  • Web root is the build folder
  • Dotfiles denied
  • All values rotated

Copy-paste fix prompt

My site serves its .env file. Change the server/deploy config so only the build directory is public, add a rule that returns 404 for any path starting with '/.', keep .env* gitignored, and give me a list of every variable in the file so I can rotate them.

FAQ

My scanner says /.env returns 200 but it's my homepage. Am I exposed?

No. That is a soft-404 from an SPA catch-all. A real exposure returns the file's KEY=value content.

Is renaming the file enough?

No. Remove it from the public directory and rotate the secrets it contained.

Check your deployed app in ~25 seconds

Free passive scan: leaked keys, Supabase exposure, public config files and headers.

Run a free scan

Related