.env Exposure.

Security Sensitive File Exposure

Environment files contain database credentials and API keys — must not be public

What does this check test?

This check tests whether `.env` files are publicly accessible by requesting common paths like `/.env`, `/.env.local`, `/.env.production`, and `/.env.backup`. Environment files typically contain database connection strings, API keys, secret tokens, SMTP credentials, and other secrets that should never be served to the public. Even a partial `.env` file exposure can provide an attacker with everything needed to compromise your application and its connected services.

Why does it matter?

A leaked `.env` file is one of the most critical exposures possible. It frequently contains database passwords, AWS access keys, Stripe secret keys, JWT signing secrets, and other credentials that grant direct access to your infrastructure. Automated scanners continuously probe for `.env` files across the internet, and exposed credentials are often exploited within minutes. A single `.env` leak can result in data breaches, cryptocurrency mining on your cloud account, or complete infrastructure takeover.

Who is affected?

Any application that uses environment files for configuration is at risk, which includes virtually all modern web applications built with Node.js, Python, Ruby, PHP, or Go frameworks. Applications deployed to shared hosting, misconfigured Nginx/Apache servers, or platforms where the web root includes the project root are most commonly affected. Teams using `.env` files in development should ensure their deployment process excludes these files entirely.

Where does this apply?

The `.env` file typically lives in the project root directory. If the web server's document root is the same as the project root (common in PHP and some Node.js setups), the file may be directly accessible. Check paths like `/.env`, `/.env.local`, `/.env.production`, `/.env.backup`, `/.env.old`, and `/.env.save`. Also check for `.env` files in subdirectories if directory traversal is possible.

How to fix it

Block access to dotfiles at the web server level. For Nginx:

nginx

location ~ /\. {
    deny all;
    return 404;
}

Apache

apache

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

Ensure your `.gitignore` includes `.env*` to prevent accidental commits. Use a secrets manager (AWS Secrets Manager, HashiCorp Vault, Doppler) instead of `.env` files in production. If you suspect an `.env` file was exposed, immediately rotate all credentials contained in it. Add `.env` to your web server's deny rules, not just your application's ignore list.

References

AppVet checks .env Exposure automatically

Run a free security scan and get a full report with actionable fixes, including a Fix with AI prompt you can paste into any coding tool.

Run Audit

← All checks