Committed .env files and missing .gitignore rules
Your .env file usually holds every password, database URL, and API key your app needs. Committing it to GitHub, even briefly, exposes all of those at once. This check looks for an exposed .env in your repo and verifies that your .gitignore actively protects future ones.
#What goes wrong
Many AI tools create a working .env file as part of their setup and forget to add it to .gitignore. The first git add . then sweeps it into a commit. Sometimes the file is named .env.local or .env.production, which feels safer but is just as public once pushed.
#Why it matters
There are public services that index every .env file ever pushed to GitHub. Attackers do not have to find your repo by name. They find it because the secrets inside match what they are scanning for. A single exposed .env can give an attacker your database, your email provider, your payment processor, and your AI credits, all in one file.
#How Heimdall checks for this
Heimdall scans the repository tree for any file matching the .env pattern that is not an example or template. It also reads your .gitignore and verifies that .env entries are present so future files stay protected. Two separate findings are reported: one for the exposed file (if any) and one for missing gitignore coverage.
#How to fix it
Remove the file from tracking with git rm --cached .env, add .env, .env.local, .env.production, and .env*.local to .gitignore, then rotate every secret that was inside. Removing the file does not erase git history, so rotation is non-negotiable. Use a secret manager or your hosting provider's environment variable UI to set the new values.
Frequently asked questions
I just committed my .env five minutes ago. Is it too late?
Should I commit .env.example?
Can I purge the .env from git history?
Run this check on your own repo
Heimdall scans your GitHub repo for this and 16 other issues in under a minute.