Your .env File Might Be Public Right Now

#webdev #security #wordpress #devops

Many of us use .env files to manage environment-specific configurations, especially in WordPress development. These files often contain sensitive credentials for databases, API keys, and other critical services. The problem is, these files can, and often are, inadvertently exposed on production servers. This isn't just a theoretical risk; it's a common oversight that can have severe consequences.

The .env Exposure Vector

When you deploy a WordPress site, especially if you're not careful about what you include in your deployment package or what gets pushed to the webroot, your .env file can end up accessible to anyone with a browser. This is usually because it's accidentally copied into the public directory alongside your WordPress core files.

Checking for Exposure with curl

The simplest way to check if your .env file is exposed is to try fetching it directly using curl. If your web server is configured to serve it, you'll get its contents.

To check for .env:

curl -I yourdomain.com/.env

The -I flag tells curl to fetch only the headers. Look for a 200 OK status code. If you see that, you can then try fetching the content:

curl yourdomain.com/.env

If you get a response that looks like a .env file (e.g., DB_NAME=your_db_name), it's exposed.

Other Common Leaks

It's not just .env files. Developers also sometimes leave other sensitive files accessible:

.git/HEAD: If your .git directory is accidentally deployed to the webroot, fetching .git/HEAD might reveal the current branch you're on. This gives an attacker insight into your development workflow and potential vulnerabilities associated with older branches.
```
curl -I yourdomain.com/.git/HEAD
```
wp-config.php~: Many editors create backup files for configuration files. If these backups are not excluded from deployment and end up in the webroot, they can leak your database credentials.
```
curl -I yourdomain.com/wp-config.php~
```
debug.log: While not as critical for direct credential theft, leaving debug logs accessible can reveal internal workings, file paths, and potentially error messages that hint at other system vulnerabilities.
```
curl -I yourdomain.com/wp-content/debug.log
```

The Real Risk: Credential Theft and Source Code Exposure

The immediate and most significant risk is credential theft. A publicly accessible .env file, or a backup of wp-config.php, often contains your database username, password, database name, and sometimes API keys for third-party services. With these credentials, an attacker can:

Access and tamper with your database, potentially stealing user data, injecting malicious content, or deleting everything.
Gain access to your WordPress admin panel through brute-force attacks on stolen credentials.
Use your API keys to incur costs on your behalf or access sensitive information on integrated services.

Exposure of .git related files can indirectly aid attackers by revealing branch names, potentially pointing to unpatched vulnerabilities in older code.

Fixing the Exposure: Deny Rules and Webroot Exclusion

The fix involves two primary strategies: preventing direct web access and ensuring sensitive files are never in the webroot.

1. Server Configuration Deny Rules

The most robust solution is to configure your web server to explicitly deny access to these files.

For Apache (.htaccess):

Add these lines to your .htaccess file in the webroot:

<FilesMatch "^\.(env|\.git/HEAD|wp-config\.php~|debug\.log)$">
    Order allow,deny
    Deny from all
</FilesMatch>

For Nginx:

Add these rules to your server block configuration for your site:

location ~* ^/(.env|\.git/HEAD|wp-config\.php~|debug\.log)$ {
    deny all;
}

If you use a subdirectory for logs, like wp-content/debug.log, you'll need to adjust the Nginx location accordingly:

location ~* ^/wp-content/(debug\.log)$ {
    deny all;
}

These rules tell the web server that if any request matches these filenames, it should immediately return a forbidden error instead of serving the file's content.

2. Remove Backups and Sensitive Files from Webroot

Beyond deny rules, the best practice is to ensure these files are never copied into your webroot in the first place.

.env files: These should always reside in the directory above your webroot. For example, if your webroot is /var/www/html/yourdomain.com/public_html, your .env file should be at /var/www/html/yourdomain.com/.env. Your application, typically via a framework or WordPress plugin, will then read this file.
.git directories: When deploying, ensure you're not deploying the entire .git directory. Use deployment tools that only copy necessary application files. Git hooks or build scripts can be used to clean up .git artifacts before deployment.
Editor backups: Configure your text editor or IDE to not save backup files in the project directory, or ensure they are excluded from your deployment process.
Debug logs: Configure WordPress to log debug information to a file outside the webroot, if possible, or at least ensure the log file itself is protected by server configuration.

By implementing these checks and preventative measures, you significantly reduce the attack surface for your WordPress sites and protect sensitive credentials and code.

SiteVett checks this automatically as part of a free website QA scan with 60+ checks across security, SEO, content, performance, and more.