Hardening wp-config.php : 5 Essential Constants and Rules to Lock Down Your WordPress Configuration

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) or 640 (read/write by owner, read by group, zero access for everyone else).
• Typical WordPress core files sit at 644 and directories at 755, so tightening wp-config.php to 600 ensures 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.

1. If your site lives in /var/www/html , move wp-config.php one level up into /var/www/ .
2. WordPress locates and parses the file seamlessly without any custom path tweaks.
3. 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:

1. 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/)

2. Overwrite the existing AUTH_KEY,SECURE_AUTH_KEY,and corresponding salt definitions in wp-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.