Every WordPress site has a single point of failure that holds the keys to the entire infrastructure: wp-config.php. It stores your database credentials, system paths, cryptographic salts, and runtime configuration. If they gain write access, injecting persistent backdoors or hijacking the entire application takes just seconds.
Directory traversal attacks – where automated bots servers attempting to read or download configuration files – consistently make up over a quarter of blocked firewall requests (around 27.1%) during major scanning campaign. In nearly every case, wp-config.php is target number one.
Hardening this file is not complicated, but it does require a layered approach: locking down file system permissions, blocking web traffic at the web server layer, relocating the file when feasible, and defining key security constants in PHP.
1. Set Strict File Permissions
Many shared and unmanaged environments default to overly permissive file modes like 666 or 777, allowing other local processes or system accounts to read and write to sensitive files.
The rule for wp-config.php is simple: grant only the exact permissions needed for PHP to read the file, and noting more.
- Standard Hardening: Set the file to
600(read and write only by the owner) or640(read/write by owner, read by group, zero access for everyone else). - Typical WordPress core files sit at
644and directories at755, so tighteningwp-config.phpto600ensures other users on a shared server cannot inspect your database credentials.
Run this command from your WordPress root directory via SSH:
chmod 600 wp-config.php
2. Block Direct Web Requests at the Server Level
Even if your file permissions are solid, direct HTTP queries to wp-config.php should be cut off immediately by your web server software before they hit PHP.
For Apache (.htaccess)
Place this snippet at the top of your root .htaccess file, making sure it sits outside the # BEGIN WordPress and # END WordPress blocks so core updates don’t overwrite it:
Apache
<Files “wp-config.php”>
Order Allow, Deny
Deny from all
</Files>
For Nginx (nginx.conf)
Add a dedicated matching block inside your server configuration:
Nginx
location ~* wp-config\.php {
deny all;
return 404;
}
Tip: Returning a 404 Not Found instead of a 403 Forbidden prevents automated reconnaissance tools from verifying that the file actually exists on that path.
3. Relocate wp-config.php Above the Web Root
One of the cleanest physical isolation techniques supported natively by WordPress is moving the configuration file completely outside the public document directory.
WordPress automatically searches the parent directory if wp-config.php is missing from the root folder.
- If your site lives in
/var/www/html, movewp-config.phpone level up into/var/www/. - WordPress locates and parses the file seamlessly without any custom path tweaks.
- Because the parent directory is inaccessible to public web requests, browsers cannot reach the file even during server misconfigurations.
(Note: Verify this in staging first, as specific multisite setups or non-standard nested document roots may require explicit path definitions.)
4. Lock Down Core Security Constants
WordPress includes several runtime constants that remove risky administrative features and protect against administrative takeover escalation.
All constants should be added directly above the line that reads:
/* That's all, stop editing! Happy publishing. */
Disable the In-Dashboard File Editor
The built-in theme and plugin code editors allow administrators to modify PHP code directly from wp-admin. If an administrative session or account is compromised, attackers can immediately drop PHP webshells via this editor. Disable it completely:
PHP
define(‘DISALLOW_FILE_EDIT’, true);
Disallow Plugin and Theme Modifications (Optional)
If your deployment workflow runs through Git, CI/CD, or WP-CLI and you want to prevent all dashboard-level plugin/theme installations and updates:
PHP
define(‘DISALLOW_FILE_MODS’, true);
Enabling DISALLOW_FILE_MODS also automatically enables DISALLOW_FILE_EDIT behind the scenes.
5. Manage Security Salts and Debug Logging
Sensitive session tokens and diagnostic error handling are both managed directly inside wp-config.php.
Invalidate Active Sessions with Fresh Salts
WordPress uses eight cryptographic keys and salts to sign and verify user authentication cookies. If an Unauthorized user accesses your database or intercepts a cookie, rotating these salts immediately destroys all active sessions across every user account:
- Grab a clean set of keys from the official generator:
[https://api.wordpress.org/secret-key/1.1/salt/]
(https://api.wordpress.org/secret-key/1.1/salt/)
- Overwrite the existing
AUTH_KEY,SECURE_AUTH_KEY,and corresponding salt definitions inwp-config.php.
Silence Front-End Errors While Keeping Server Logs
Default PHP error outputs leaks absolute server paths, database errors, and plugin stack traces directly to visitors and attackers. To suppress frontend output while logging issues safely in the background, use this debugging configuration:
PHP
// Keep debugging active for logging purposes only
define(‘WP_DEBUG’, true);
// Prevent errors from printing directly to the browser
define(‘WP_DEBUG_DISPLAY’, false)
// Save error messages to /wp-content/debug.log
define(‘WP_DEBUG_LOG’, true)
Make sure your web server blocks public downloads of /wp-content/debug.log,or remove the log once active troubleshooting is finished.
Complete Production Hardening Blueprint
Here is a consolidated snippet ready to drop into your wp-config.php right before the /* That's all, stop editing! */ comment:
PHP
/**
* Core Security & Hardening Rules
*/
// 1. Enforce minor automatic core security updates
define(‘WP_AUTO_UPDATE_CORE’, ‘minor’);
//2. Disable theme and plugin file editing in wp-admin
define(‘DISALLOW_FILE_EDIT’, true);
//3. Secure error handling: log privately, hide from public view
define(‘WP_DEBUG’, true);
define(‘WP_DEBGUG_DISPLAY’, false);
define(‘WP_DEBUG_LOG’, true);
/* That’s all, stop editing! Happy publishing. */
Taking ten minutes to implement proper file permissions, web server deny rules, and core constants eliminates the most common configuration vulnerabilities without adding any overhead to your server.