Sensitive File Exposure

What SecurityStatus Checks

• Environment files: .env, .env.local, .env.production, .env.backup
• Configuration files: config.php, database.yml, settings.py, wp-config.php
• Backup files: site.zip, backup.sql, database.sql, *.bak, *.old
• Version control files: .git/config, .svn/entries (which expose your code history)
• Log files: error.log, access.log, debug.log that may contain credentials or PII

Why This Matters

A single exposed .env file can contain your database password, AWS secret key, Stripe API key, and dozens of other credentials — everything an attacker needs to completely compromise your infrastructure. This is not theoretical: automated scanners find and exploit exposed .env files within minutes of them being published.

How to Fix It

1. 1

   Block sensitive file extensions in your web server

   For nginx: `location ~* \.(env|bak|sql|log|config)$ { deny all; return 404; }`. For Apache, add to .htaccess: `<Files ~ '\.(env|bak|sql)$'> Order allow,deny Deny from all </Files>`.

2. 2

   Move sensitive files outside the web root

   Environment files and configuration files should live outside the publicly accessible directory (outside /public, /www, or /html). Reference them with absolute paths from your application code.

3. 3

   Block .git directory access

   Add `location /.git { deny all; return 404; }` to your nginx config. A publicly accessible .git directory allows attackers to download your entire source code history.

4. 4

   Audit what is exposed

   Use SecurityStatus or tools like dirsearch to scan your domain for common sensitive file paths. Fix any exposures immediately and rotate any credentials that may have been exposed.

5. 5

   Rotate all potentially exposed credentials

   If you find a .env or config file was publicly accessible, assume all credentials in it are compromised. Rotate every secret immediately: database passwords, API keys, OAuth credentials, everything.

Frequently Asked Questions

Related Guides