If a deployed app's .env file or .git directory is reachable at a public URL, anyone can download it directly — no exploit required, just a GET request. A public .env file typically contains every secret the app uses in one place (database URLs, API keys, signing secrets), and a public .git/config or .git directory can expose your full commit history, including secrets that were committed and later "removed" but still exist in prior commits.
Why this is rated critical
Most individual findings expose one thing — a header, a cookie flag, one key. An exposed .env exposes everything the app was configured with at once, in one file, with no further work required. That's why this class of finding is treated as critical severity rather than being scored alongside individual header or cookie issues.
How it ends up public
This typically happens when a deploy step copies the entire project directory into the served web root instead of just the build output — common on simple static hosts or misconfigured deploys where .env, .git, and other dotfiles sit alongside index.html with nothing blocking direct access to them.
How to fix it
Confirm your deploy only publishes the build output directory (e.g. .next, dist, build), never the project root. Add explicit deny rules for .env and .git at the web server or CDN level as a second layer of defense. If either was ever exposed, rotate every secret .env contained — treat it as compromised regardless of how long it was live.
Frequently asked
If I remove the .env file from my repo, is the leak fixed?
Only going forward. If it was ever publicly reachable, assume every value in it has been seen and rotate all of them — removing the file doesn't undo an exposure that already happened.