An exposed .env or .git on your live site
In one paragraph
Even with clean code, a misconfigured deployment can serve files that should never be public — a .env full of secrets, or a .git directory that lets anyone reconstruct your entire source. Attackers scan for these paths automatically. The fix is to make sure they 404 on your live domain, add security headers, and keep verbose errors out of production.
The attack surface isn't just your repo — it's the running site. If your host serves the project directory as-is, files meant for your machine only (.env, .git, backups, config) become downloadable. One request to the right path can hand over every secret at once, or the full commit history.
Why it happens
The whole project directory is served
Some deployments serve every file in the project root, including dotfiles. A request to /.env or /.git/config then returns real content.
Secrets and history travel with the deploy
A .env that wasn't ignored, or a .git folder left in the deployed output, carries your secrets and source straight to production.
Verbose errors that overshare
Production error pages that print stack traces, file paths or connection strings hand attackers a map of your app.
Check it yourself
- On your live domain, load /.env and /.git/config — both should return 404, not content.
- Trigger an error and confirm the page doesn't print stack traces, paths, or connection strings.
- Check for HTTPS and basic security headers on your responses.
How to fix it
- Ensure .env and .git are never deployed — git-ignore them and confirm they're not in the build output.
- Rotate any secret that was reachable on the live site.
- Turn off verbose errors in production and add standard security headers.
Not sure if your app has this?
SafeLaunch checks your repo and live site in about 30 seconds — this issue and every other — and gives you a prompt to paste back into your builder to fix each finding.
Most common in apps built with
Exposed .env / .git FAQ
How do I check if my .env is exposed?+–
Load /.env on your live domain. If it returns the file contents instead of a 404, it's public — rotate every secret in it and fix the deployment so it isn't served.
Why is an exposed .git directory dangerous?+–
A served .git lets anyone download your full commit history and reconstruct your source code — including any secrets that were ever committed, even if later removed.
My code is fine — can my live site still leak?+–
Yes. Exposed files, missing HTTPS or headers, and verbose errors are deployment-level issues that leak regardless of how clean your code is. Check the running site, not just the repo.