Verifiedapp Blog
Exposed Files

.env exposed: how a single file hands attackers your whole stack

· 2 min read
#dotenv#exposed-files#secrets

One file, everything

The .env file exists to keep configuration out of your code: instead of hardcoding a database URL or an API key, you read it from the environment. That is good practice. The danger is what the file becomes — a single document holding your database credentials, third-party keys, signing secrets and tokens, all in plain text. If that one file becomes public, an attacker does not need to break anything. They just read it.

How it ends up public

The .env is supposed to live on the server and never be served to browsers. It leaks when that boundary breaks:

  • The whole project folder, including .env, gets deployed into the web root.
  • The web server is not configured to block dotfiles, so /.env is served like any other file.
  • A Docker image or build artifact bundles the .env and ships it.
  • A copy like .env.backup, .env.old or .env.local is left behind in a reachable path.

None of these require a mistake in your code. They are deployment and configuration slips — which is exactly why they are so common.

How attackers find it

They do not search; they just ask. Automated tools request a fixed list of high-value paths on every site they encounter, and /.env is at the top of that list alongside /.git/config, /config.json and a handful of backups. If the file answers with your configuration, it is harvested instantly. This is untargeted, around-the-clock, and free for the attacker — which is why a freshly deployed .env can be drained within minutes.

How to make sure yours is safe

  • Keep .env out of the web root. It should never be inside the folder your server publishes.
  • Block dotfiles at the server. Add a rule that denies access to any path beginning with a dot — .env, .git, .aws and friends — so a misplaced file still cannot be served.
  • Do not bundle it into images or artifacts. Inject configuration at runtime via real environment variables or a secrets manager, not a committed file.
  • Hunt the copies. Check for .env.backup, .env.save, .env.local and similar leftovers in reachable paths.
  • Rotate if it was ever exposed. If /.env was reachable, assume every secret in it is compromised and rotate them all.

Check your own domain

The only way to know whether /.env answers on your site is to request it the way an attacker would. An automated scan does exactly that across the common leaked-file paths — scan your site and confirm the door is shut.

Related reading

FAQ

Does this affect static sites and frameworks too?
Yes. Any deployment that copies the project folder to the server can carry a .env with it, and any server that does not block dotfiles can serve it. Static hosts and SSR frameworks are both common places for this to slip through.
I block /.env — am I fully safe?
Blocking the exact path helps, but also block all dotfiles and hunt for non-dot copies like env.backup or config.json. The safest approach is to keep the file out of the web root entirely and inject config at runtime.
What should I do if my .env was reachable?
Treat every secret in it as leaked. Rotate all of them — database passwords, API keys, signing secrets — remove the file from the public path, and review service logs for unexpected access.

Keep reading