Common Types of Sensitive File Exposure in WordPress (And How to Fix Them)

Sensitive Data Exposure consistently ranks in the OWASP Top 10 web application security risks. For WordPress sites, this usually happens not because of complex code vulnerabilities, but due to simple housekeeping errors.

Developers and administrators often leave backup files, configuration snippets, or debug logs in publicly accessible directories. These files are invisible to the average visitor but are easily discovered by bots and scanners.

If a hacker finds a single exposed database backup or configuration file, they often gain instant, full control over your website.

In this guide, we will categorize the most dangerous types of sensitive file exposure in WordPress and provide the exact server rules to block them.

---

1. Configuration File Backups (The #1 Killer)

This is the most common and most dangerous error.

When editing wp-config.php, prudent administrators make a backup. However, if they rename the file to something like wp-config.php.bak, wp-config.php.old, or wp-config.txt, the web server (Apache/Nginx) no longer treats it as a PHP script.

Instead of executing the code, the server serves the file as plain text. Anyone who guesses the filename can download it and see your database credentials, authentication keys, and table prefixes.

Common Culprits:

• wp-config.php.bak
• wp-config.php.old
• wp-config.php.save
• wp-config.txt
• .wp-config.php.swp (Created by VIM editor)

How FunSentry Helps:

FunSentry specifically fuzzes your root directory for 30+ variations of backup filenames to ensure you haven’t accidentally left your credentials exposed.

---

2. Database Exports (.sql, .zip)

Developers often export the database to migrate a site or create a manual backup. If this file is saved in the root directory or /wp-content/ and not deleted immediately, it becomes a goldmine for attackers.

A file named db_backup.sql or localhost.sql allows an attacker to download your entire database—including user emails, hashed passwords, and customer data.

Common Culprits:

• backup.sql
• users.sql
• dump.sql
• wordpress.zip
• db.tar.gz

The Fix: Never store database dumps in the web root (public_html). If you must transfer them, use SFTP, or delete them immediately after use.

---

3. Debug Logs (debug.log)

As discussed in our wp-config.php guide, enabling WP_DEBUG_LOG creates a file at /wp-content/debug.log.

While useful for development, this file logs every PHP error, warning, and notice. It often reveals:

• Server file paths (/var/www/html/...)
• Plugin failures
• Database query errors
• Sometimes even sensitive data passed in variables

If left public, it provides attackers with a roadmap of your site’s internal structure and potential weak points.

---

4. Version Control Directories (.git)

If you use Git to deploy your WordPress site (a best practice!), you must ensure the .git directory is not accessible via the browser.

If yoursite.com/.git/HEAD is accessible, attackers can use tools like git-dumper to download your entire repository, effectively reconstructing your source code, including previous commits that might contain hardcoded API keys or passwords.

Common Culprits:

• /.git/
• /.gitignore
• /.svn/ (for older Subversion repos)

---

5. Environment Files (.env)

Modern WordPress development often uses .env files (popularized by frameworks like Laravel or Roots/Bedrock) to store environment variables.

These files contain the “keys to the kingdom”: database passwords, API keys (Stripe, AWS, Mailgun), and debug settings. Since .env is a plain text file, web servers will serve it to anyone who asks unless explicitly told not to.

Common Culprits:

• .env
• .env.production
• .env.local

---

6. System & Editor Temporary Files

Operating systems and text editors leave behind “trash” files that developers often forget about.

• macOS: Generates .DS_Store files. While not critical, they reveal your directory structure to attackers.
• VIM/Nano: If an editor crashes, it leaves swap files like .filename.swp.
• IDEs: VS Code or PHPStorm project folders (.vscode/, .idea/) can reveal project settings.

---

How to Check and Fix These Exposures

Step 1: Scan Your Site Immediately

The fastest way to check if you are currently exposed is to use a scanner. FunSentry performs a non-intrusive scan that checks for:

1. Publicly accessible wp-config backups.
2. Exposed .git repositories.
3. Accessible debug.log files.
4. Common database dump filenames.
5. Status of directory indexing (listing files).

Step 2: Block Access via Server Config

You can block access to all these file types globally using your web server configuration.

For Apache (.htaccess):

Add this to the top of your .htaccess file:

Apache

# ─── SECURITY: Block Sensitive Files ───
<FilesMatch "^(wp-config\.php|php\.ini|php5\.ini|readme\.html|license\.txt)">
    Order Allow,Deny
    Deny from all
</FilesMatch>

# Block access to backup and source files
<FilesMatch "\.(bak|config|sql|fla|psd|ini|log|sh|inc|swp|dist)|~">
    Order Allow,Deny
    Deny from all
</FilesMatch>

# Block .git and .env files
<FilesMatch "^\.">
    Order Allow,Deny
    Deny from all
</FilesMatch>

# Disable Directory Browsing
Options -Indexes

For Nginx:

Add this to your server block:

Nginx

# Block access to hidden files (starts with dot)
location ~ /\. {
    deny all;
}

# Block specific sensitive file extensions
location ~* \.(bak|conf|dist|fla|inc|ini|log|psd|sh|sql|swp)|~ {
    deny all;
}

# Explicitly block wp-config.php
location = /wp-config.php {
    deny all;
}

---

Summary Checklist

File Type	Risk Level	Common Location	Solution
Config Backups	🛑 Critical	Root (/)	Delete file; Block .bak extension
Database Dumps	🛑 Critical	Root or /wp-content/	Delete immediately; Move to non-public dir
.env Files	🛑 Critical	Root	Block access to all .* files
.git Directory	🔴 High	Root	Block access to .git folder
debug.log	🟠 Medium	/wp-content/	Disable WP_DEBUG_LOG or block .log extension
.DS_Store	🟡 Low	Any folder	Block access to .* files

Don’t wait for a bot to stumble upon your old-backup.zip. Take 5 minutes today to clean up your file system and implement the blocking rules above.

Not sure if your files are exposed?

Run a free FunSentry Scan now. Our scanner checks for over 50 types of sensitive file exposures and gives you a pass/fail report instantly.