When WordPress debugging is enabled, errors and warnings are written to a log file at /wp-content/debug.log. This is incredibly useful during development. On a production site, however, a publicly accessible debug log is a serious security risk. Anyone who knows the URL can read it, and it often contains far more sensitive information than most site owners realize.
What the Debug Log Contains
The debug.log file is not just a list of PHP warnings. Depending on your site's configuration and the plugins you run, it can contain:
- PHP errors and warnings: These include file paths, line numbers, and function names. An attacker can use this information to map your server's directory structure and identify vulnerable code.
- Database query errors: Failed queries sometimes include table names, column names, and even fragments of the data being queried. This gives attackers insight into your database schema.
- Plugin and theme errors with stack traces: Stack traces reveal which plugins you use, their versions, and how they interact. This is valuable for planning targeted attacks against known plugin vulnerabilities.
- API keys and credentials: Poorly written plugins sometimes log API responses or connection errors that include authentication tokens, API keys, or even passwords in plain text.
- User data and email addresses: Errors related to user registration, form submissions, or email sending can include personal data like names, email addresses, and form input.
- File system paths: Every PHP error includes the full server path to the file where it occurred. This reveals your hosting directory structure, username, and sometimes your hosting provider.
Why the Debug Log Is Publicly Accessible
By default, WordPress stores debug.log inside the wp-content directory. This directory is served by your web server just like any other folder in your WordPress installation. Unless you have specifically blocked access, anyone can type https://yoursite.com/wp-content/debug.log into a browser and read the file.
Many hosting providers do not block this path by default. And because the file grows over time without any automatic rotation, it can accumulate months or even years of sensitive error data.
How Attackers Find Debug Logs
Automated scanners routinely check for /wp-content/debug.log on every WordPress site they encounter. It is one of the first paths that security scanning tools test. Some attackers also check for common variations:
/wp-content/debug.log(default location)/debug.log(sometimes misconfigured)/wp-content/uploads/debug.log(another common misconfiguration)/error_logor/error.log(generic error log names)
These scans are cheap, fast, and fully automated. If your debug log is accessible, it will be found.
Block Access with .htaccess (Apache)
If your server runs Apache, add this rule to the .htaccess file inside your wp-content directory:
Order allow,deny
Deny from all
This tells Apache to deny all HTTP requests for the debug.log file. The file still exists on disk and PHP can still write to it, but no one can download it through a browser. If you want to block all log files as a precaution, you can use a broader rule:
Order allow,deny
Deny from all
Block Access with Nginx
For Nginx servers, add this location block to your server configuration:
location ~* /debug\.log$ {
deny all;
return 404;
}Returning a 404 instead of a 403 is a deliberate choice. A 403 (Forbidden) response tells an attacker that the file exists but is protected. A 404 (Not Found) gives away nothing. After adding this rule, reload the Nginx configuration with sudo nginx -s reload.
Move the Log File Outside the Web Root
The most secure approach is to store the debug log in a directory that your web server cannot serve at all. In your wp-config.php, set the WP_DEBUG_LOG constant to an absolute path outside your web root:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', '/home/youruser/logs/wp-debug.log');
define('WP_DEBUG_DISPLAY', false);The /home/youruser/logs/ directory must exist and be writable by the web server process. Setting WP_DEBUG_DISPLAY to false is equally important: it prevents PHP errors from being shown directly on your pages, where visitors (and attackers) could see them.
Disable Debug Mode on Production Sites
On a live production site, debugging should almost always be turned off. There is rarely a good reason to leave it enabled permanently. Set these values in wp-config.php:
define('WP_DEBUG', false);
define('WP_DEBUG_LOG', false);
define('WP_DEBUG_DISPLAY', false);If you need to debug an issue on production, enable debug mode temporarily, reproduce the problem, check the log, and then disable it again immediately. Never leave debugging enabled "just in case." The risk is not worth the convenience.
Monitor Debug Log File Size
If you do keep debugging enabled on a staging or development site, monitor the size of the debug log. Without log rotation, it can grow to hundreds of megabytes and eventually fill your disk. Consider setting up a cron job to rotate or truncate it:
# Rotate debug.log weekly, keep 4 backups
# Add to /etc/logrotate.d/wp-debug
/home/youruser/logs/wp-debug.log {
weekly
rotate 4
compress
missingok
notifempty
}What to Do If Sensitive Data Was Already Exposed
If your debug log was publicly accessible and contained sensitive information, take these steps immediately:
- Delete the debug log file: Remove it from the server right away.
- Rotate all API keys and credentials: Any API key, password, or token that appeared in the log should be considered compromised. Regenerate them.
- Change database passwords: If database connection errors were logged, the credentials may have been exposed.
- Check for unauthorized access: Review your server access logs for requests to
debug.log. If someone downloaded it, assess what information they obtained. - Notify affected users: If personal data (emails, names, form submissions) was logged, you may have a GDPR or privacy obligation to notify affected individuals.
Verify with InspectWP
InspectWP checks whether /wp-content/debug.log is publicly accessible on your site. After securing the file (blocking access, moving it, or disabling debug mode), run a new InspectWP scan. The security section of the report will confirm whether the file is still reachable. If the warning persists, clear any server-side caches and verify that your .htaccess or Nginx rules are applied to the correct directory.