The fix, in one snippet
location ~ /\.env { deny all; return 404; }
# keep it outside the web root entirelyIllustrative values. Change the paths, hostnames and options to match your own site before using it.
The sections below explain what is tested, why it matters and the alternatives.
What we test
Scan.now requests /.env, and if that is absent, /.env.local and /.env.production. A finding requires an HTTP 200 whose body looks like a dotenv file: at least two lines matching NAME=value with an upper-case identifier, and no HTML markup. Typical keys that confirm the match are APP_KEY, DB_PASSWORD, DATABASE_URL, AWS_SECRET_ACCESS_KEY, MAIL_PASSWORD, SECRET_KEY and STRIPE_SECRET_KEY. The report lists which key names were seen so you can gauge the blast radius; values are never shown or stored. The check is rated critical because the file is a direct credential leak with no further step required. See also exposed-git-directory and exposed-backup-files, which frequently accompany it.
Why it matters
Laravel, Symfony, Node, Django and Rails projects all use .env files to hold every secret the application needs. Serving one to the internet hands over the database (often reachable from the internet as well), cloud credentials (an AWS key means every S3 bucket the role can see), the transactional-mail account (immediately used for spam and phishing from your domain), and payment-provider keys. Automated scanners request /.env across the whole IPv4 space; exposures are typically exploited within hours, and stolen cloud keys are resold. Framework secrets are dangerous on their own: an application key lets an attacker forge signed cookies and sessions, and in older Laravel releases a known APP_KEY led to remote code execution through crafted cookies (CVE-2018-15133). The exposed files guide covers the full family of leaked configuration files.
How to fix it
Keep .env outside the document root. Laravel, for example, expects only its public/ directory to be served; if your vhost points at the project root, the file is one directory too deep to be safe. Then block dotfiles regardless. nginx:
location ~ /\.(?!well-known/) {
deny all;
return 404;
}Apache 2.4:
<FilesMatch "^\.">
Require all denied
</FilesMatch>Cloudflare WAF custom rule: expression (http.request.uri.path contains "/.env"), action Block. Express serving a static directory: never point express.static at the project root; serve a dedicated public/ folder, and set dotfiles: 'deny' if it might contain any. Once blocked, assume the contents are compromised: rotate the database password, every API key, the mail credentials and the application key (which will invalidate sessions), and review cloud and mail-provider logs for unfamiliar activity. Check your access log for earlier hits:
grep -E 'GET /\.env' /var/log/nginx/access.log | headWhere this fits
Exposed .env configuration file is check 1 of 14 that the website vulnerability scanner runs under exposed files and information disclosure, ordered the way they are worth fixing. That ordering is the point: Fixing this one while the check above it still fails buys less than it looks like.
What fixing this still leaves open
Exposed .env configuration file closes one route in. Immediately below it: Exposed .git repository, where the site's .git directory is reachable over HTTP; Exposed backup or archive files, where a backup archive, database dump or editor backup copy of a configuration file is downloadable from the web root, exposing source code, credentials and user data; Exposed phpinfo() page, where a phpinfo() page is publicly reachable.
Found in the same scan
The website vulnerability scanner reports this alongside checks from other categories that are at least as serious, including Certificate chain and hostname validation, where the certificate presented for this hostname did not validate: The chain does not reach a trusted root, an intermediate is missing, the name does not match, or the certificate is self-signed or expired, and HTTPS is available, where the site could not be reached over HTTPS on port 443, or the TLS handshake failed. A single run of website vulnerability scanner answers all of them at once.
The first few lines
You are a senior web engineer. I ran a security and SEO scanner against my site and it reported the finding below. Fix it properly rather than suppressing the symptom.
Finding: Exposed .env configuration file (critical severity)
Scanner check id: exposed-env-fileThe rest of this prompt names the pages and line numbers we found the problem on, the configuration to change, and the constraints a good answer has to respect. It is free, it just needs an account so the work is not scraped wholesale.
Sign in with GoogleSigning in is free and takes one click. We store your email address and nothing else.
