How to Fix an Exposed .env File

A .env file holds the settings an app needs to run: database passwords, API keys, payment provider secrets, mail credentials. It is meant to stay on the server. With an exposed .env file, anyone who requests https://yoursite.com/.env can download it, and automated bots request that path on every site they find, all day. If a scan reports an exposed .env file on your site, treat every secret in it as already stolen.

How an Exposed .env File Happens

• The project root is the web root. The server serves the whole project folder, including .env, instead of only a public/ or dist/ folder.
• A deploy copied everything. An FTP upload or a simple copy step put the file next to index.php or index.html.
• Static hosting of the build folder includes a .env or .env.production that a build tool wrote there.
• Server rules do not block dotfiles. Many default configurations serve hidden files if they exist.
• Backups and copies, such as .env.bak or .env.old, left in a public folder.

Step 1: Confirm the Exposed .env File

curl -s -o /dev/null -w "%{http_code}\n" https://example.com/.env
curl -s https://example.com/.env | head -3

A 200 with lines like DB_PASSWORD= means you have an exposed .env file. A 403 or 404 means it is blocked or absent. Also try /.env.local, /.env.production and the same paths under any subfolder app. A security scan checks these paths for you, together with other sensitive files such as /.git/config, /.aws/credentials, /docker-compose.yml, /.npmrc and database dumps. It only reports a file when the content matches what that file really looks like, so a custom 404 page that returns 200 does not cause false alarms.

Step 2: Block Access Right Away

Blocking first stops further downloads of the exposed .env file while you work on the rest. Add a rule that denies every dotfile except /.well-known/, which is needed for certificates and security.txt.

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

<FilesMatch "^\.">
    Require all denied
</FilesMatch>

On managed hosting, check the host's documentation for blocking paths, or move the file out of the public folder (step 5). Request the URL again and confirm it now returns 403 or 404.

Step 3: Rotate Every Secret in the File

Blocking does not undo the leak. An exposed .env file has to be treated as public. Bots may have copied the file minutes after it went live. Treat each value as compromised and replace it:

• Database passwords: create a new password, update the app, then remove the old one.
• API keys for payment, email, cloud, AI and maps services: generate new keys in each dashboard and revoke the old keys. Revoking is the important part.
• App secrets such as APP_KEY, JWT or session secrets: rotating these logs users out, which is the right outcome after a leak.
• Mail and SMTP credentials, OAuth client secrets and webhook signing secrets.

Step 4: Check for Abuse

• Search your web server logs for requests to /.env that returned 200, to estimate when the leak started and who downloaded it.
• Check each provider's usage and billing for unexpected spikes, new users, new API keys or unknown IP addresses. Cloud and AI keys are often abused within hours.
• Review database logs for logins from unknown addresses.
• If personal data could have been accessed, check your obligations under GDPR or other data protection laws.

Step 5: Fix the Root Cause So an Exposed .env File Cannot Happen Again

• Point the web server at the public folder only, for example public/ in Laravel or the build output folder for static sites, never the project root.
• Keep secrets out of deploy artifacts. Use your host's environment variable settings or a secrets manager rather than shipping a .env file.
• Add .env* to .gitignore and keep only a .env.example with placeholder values in the repository.
• Keep the dotfile deny rule as a permanent safety net.

Secrets also leak through code, not just through servers. If a key was ever committed, it is still in your git history even after you delete it. See secrets in git history and how to fix hardcoded secrets in code. The repo scanner finds keys in source code before they ship.

Front-End Secrets Are Exposed Too

Variables with prefixes such as NEXT_PUBLIC_, VITE_ or REACT_APP_ are built into the JavaScript bundle on purpose. Anyone can read them. Never put a secret key in one. The API key leak checker scans a page's HTML and script files for keys that should not be there.