A configuration or password file can be downloaded
sec_exposed_envShort answer
Anyone can download a configuration or password file from your site, for example /.env. These files hold database passwords, API keys, mail and payment credentials. Block access immediately, then change every secret the file contains: bots request /.env around the clock, so assume the values have already been copied.
Why it matters
.env is among the most requested paths on the internet; automated scanners fetch it from every domain they find, often within hours of a site going live. With its contents an attacker can log in to your database, send mail as you, run up bills on your cloud or payment accounts, or forge sessions. An exposed .htpasswd hands over password hashes that can be cracked offline.
A break-in that follows often brings injected spam pages, malware and a "This site may be hacked" label in Google results, which do hurt search traffic. Blocking quickly and replacing the secrets is the only safe response.
How Glimana detects it
Glimana requests /.env, /.env.backup, /.env.production and /.htpasswd over HTTPS and reads only the first 2 KB. An env file counts as exposed when the answer is 200 or 206, is not an HTML page, and contains at least two NAME=value lines with at least one sensitive-looking name (containing KEY, SECRET, PASS, TOKEN, DB_, DATABASE, MAIL_, AWS_, STRIPE or API). .htpasswd counts when it contains user-name and password-hash lines. Answers identical to a random non-existent address are ignored, so a catch-all page does not trigger it. The issue shows only the variable names, never their values. Critical; a new finding also sends an immediate alert e-mail.
How to fix it
Watch out
Blocking the file is not enough: every value in it must be treated as compromised. Change the database password, mail and API keys, payment and cloud credentials and OAuth secrets, and revoke the old ones at each provider. In Laravel, a new APP_KEY logs everyone out and makes data encrypted with the old key unreadable; keep the old key in APP_PREVIOUS_KEYS while you migrate. Purge your CDN cache too, and check the access logs for earlier downloads of the file.
- Find the finding in Glimana. Open Security; this check is in the Exposed files group, with the evidence from the last scan under its title. The same problem is listed under Issues › A configuration or password file can be downloaded.
-
Apply the fix on your platform.
The web server's document root must be the
public/folder, not the project folder;.envthen sits outside it and cannot be served. On shared hosting, point the domain topublic/in the hosting panel instead of copying the whole project intopublic_html. Delete stray copies such as.env.backupfrom the server entirely.Deny every hidden file except
/.well-known/(needed for certificate renewal), in the virtual host or.htaccess:RewriteEngine OnandRewriteRule "(^|/)\.(?!well-known/)" - [F]. Apache's default configuration denies.ht*files, but only if that block is still in place.In the
serverblock, before other regexlocationblocks:location ~ /\.(?!well-known) { deny all; }, thennginx -t && systemctl reload nginx. Nginx ignores.htaccess, so deny rules written for Apache do not protect you here.As an immediate shield while you fix the server: Security › Security rules › Create rule › Custom rules, expression
(starts_with(http.request.uri.path, "/.env")) or (starts_with(http.request.uri.path, "/.ht")), action Block. Then purge the cache. This only covers requests that pass through Cloudflare; anyone who knows your origin IP can still reach the file, so fix the server as well. - Check it in Glimana. Press Re-scan on the Security page (up to two scans an hour) or wait for the weekly scan on Sunday; the problem closes when the check passes.
How the fix is verified
After fixing, press Re-scan on the Security page (or wait for the weekly Sunday scan); the problem closes as soon as the check passes.