How to Stop .env and Config Files Being Served From the Web Root

What this check reads

The check runs one find across three fixed web roots and counts what comes back:

find /var/www /srv/www /usr/share/nginx/html -maxdepth 4 -type f \
  \( -name '.env' -o -name 'wp-config.php' -o -name 'config.php' -o -name 'settings.php' -o -name 'database.yml' \) | head -20

Nothing is read out of the files themselves: carrying one of those five names, inside one of those three trees, at a depth of 4 or less, is the entire test. A count of zero is the only PASS, and one match or more is a WARN, in which case the message quotes the first two paths (head -2) along with the total.

When it applies

Always runs - it is a filesystem scan, not gated on any database or web server being detected, and needs no root. Scope is fixed and narrow: exactly three roots (/var/www, /srv/www, /usr/share/nginx/html), a maximum depth of 4, five filename patterns, and only the first 20 matches (head -20). Sites served from /home/*/public_html, /opt or any other root are never scanned, so PASS means "nothing found in those three trees", not "no exposed config anywhere". Files the audit user cannot traverse to are silently skipped.

What each result means

Why it matters

Credential-bearing files inside a document root are one misconfiguration away from being served as plain text: a PHP handler outage serves wp-config.php raw; a missing dotfile deny rule serves .env. OWASP Top 10 A05:2021 Security Misconfiguration; OWASP Secrets Management Cheat Sheet; WSTG-CONF-04 "Review Old Backup and Unreferenced Files". Best practice is to keep config outside the web root and load it by path, or use environment variables injected by the service manager.

Why it fails, and when it is wrong

• WordPress requires wp-config.php next to or one level above wp-content. Moving it one directory above the document root is supported by WordPress and resolves the finding.
• Laravel, Symfony and Node projects often have .env at the project root while the real document root is public/. The file is then not served, but it is still within /var/www/<app> and will be reported. This is a WARN, not FAIL, for that reason. Verify with curl -I https://host/.env (expect 403/404) and the Hidden File Exposure web check.
• Only three common roots are searched, to a depth of 4. Sites under /home/*/public_html or /opt are not scanned.
• Files are only readable by the audit user if permissions allow; unreadable files are silently skipped (2>/dev/null).

How to fix it

find /var/www /srv/www /usr/share/nginx/html -maxdepth 4 -type f \
  \( -name '.env' -o -name 'wp-config.php' -o -name 'config.php' -o -name 'settings.php' -o -name 'database.yml' \) 2>/dev/null

location ~ /\.(?!well-known) { deny all; }
location ~* (wp-config\.php|config\.php|database\.yml)$ { deny all; }

<FilesMatch "^(\.env|wp-config\.php|database\.yml)$">
  Require all denied
</FilesMatch>

curl -sS -o /dev/null -w '%{http_code}\n' https://your-host/.env
# expected: 403 or 404

Verify the fix

# Reproduce the exact scan the check performs:
find /var/www /srv/www /usr/share/nginx/html -maxdepth 4 -type f \
  \( -name '.env' -o -name 'wp-config.php' -o -name 'config.php' -o -name 'settings.php' -o -name 'database.yml' \) 2>/dev/null
# expected after the fix: no output

# And confirm the file is not actually served (the finding that really matters):
curl -sS -o /dev/null -w '%{http_code}\n' https://your-host/.env
# expected: 403 or 404

Debugging

Sources

• OWASP Secrets Management Cheat Sheet
• OWASP Top 10 A05:2021 Security Misconfiguration
• OWASP WSTG-CONF-04 Review Old Backup and Unreferenced Files
• WordPress: Moving wp-config.php (Hardening WordPress)
• Laravel: Deployment, web server configuration (public/ as root)
• nginx: location directive
• Apache: FilesMatch

How the script reads this