Is your .env file public? How to check in two minutes

Many websites keep their passwords and API keys in a file called .env. If that file sits inside the folder your web server publishes, anyone can download it by adding /.env to your address. The same goes for the .git folder, which can be used to rebuild your entire source code.

These files are exposed more often than you might think, especially after a quick deployment by copying files to a server. Bots request /.env on websites around the clock.

Only check websites you own or have permission to test.

The two-minute check

Run these in a terminal, replacing the address with your own:

curl -s -o /dev/null -w "%{http_code}\n" https://www.example.com/.env
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.com/.git/HEAD

A 403 or 404 is what you want. A 200 needs a closer look, because some sites return a normal page for every address. Look at the content itself:

curl -s https://www.example.com/.git/HEAD | head -c 200

If you see something like ref: refs/heads/main, your Git folder is public. If /.env shows lines like DB_PASSWORD=, your secrets are public.

Other files worth checking

• Backups: .env.bak, .env.old, config.php.bak, backup.zip, site.tar.gz
• Database dumps: dump.sql, database.sql
• Editor and system files: .DS_Store, .vscode/, .idea/
• Logs: debug.log, error.log

Our free scanner checks the common ones automatically, and confirms the content before reporting a file, so a site that returns a normal page for every address does not produce false alarms.

How to fix it

The best fix is structural: keep secrets and source control outside the folder your web server serves. Then add a rule that refuses all hidden files as a safety net.

Nginx:

location ~ /\.(?!well-known) {
    deny all;
}

Apache, in your configuration or .htaccess:

RedirectMatch 404 /\.(?!well-known/)

Both rules keep /.well-known/ working, which is used for HTTPS certificates and security.txt. Afterwards, run the two-minute check again to confirm.

If a file was exposed

Fixing the server rule is not enough on its own. Assume anything in the file was copied.

1. Change every password and rotate every key that was in the file.
2. Check your server logs for requests to /.env or /.git/ that returned 200, to see when it was downloaded.
3. If your source code was exposed through .git, check it for other secrets and for anything an attacker could use, such as admin addresses or internal services.

Two minutes of checking now is much cheaper than finding out from someone else.