Secure wp-config.php in WordPress

The file wp-config.php in the root directory of every WordPress installation holds the database credentials (host, name, user, password), the secret security keys and salts as well as central configuration constants. If this file falls into the wrong hands, practically the entire website is compromised. It is therefore the single most important file to secure. This guide shows four hardening measures: generate fresh security keys, set restrictive file permissions, block direct HTTP access to the file and add protective constants such as DISALLOW_FILE_EDIT. Optionally, the file can be moved one level above the webroot. All steps can be done in about 20 minutes via SFTP/SSH and the .htaccess or nginx configuration.

Step 1: Regenerate security keys and salts

WordPress uses eight secret strings (AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY and the four matching _SALT values) to encrypt login cookies and nonces. If these values were ever public (for example in a backup that sat on the web) or were never changed, you should regenerate them. WordPress provides an official generator for this:

# Fetch current random values:
https://api.wordpress.org/secret-key/1.1/salt/

In wp-config.php, replace the existing block with the freshly generated values:

define( 'AUTH_KEY',         'hier-langer-zufallswert' );
define( 'SECURE_AUTH_KEY',  'hier-langer-zufallswert' );
define( 'LOGGED_IN_KEY',    'hier-langer-zufallswert' );
define( 'NONCE_KEY',        'hier-langer-zufallswert' );
define( 'AUTH_SALT',        'hier-langer-zufallswert' );
define( 'SECURE_AUTH_SALT', 'hier-langer-zufallswert' );
define( 'LOGGED_IN_SALT',   'hier-langer-zufallswert' );
define( 'NONCE_SALT',       'hier-langer-zufallswert' );

After saving, all logged in users are signed out – this is intended and an effective way to invalidate stolen sessions.

Step 2: Set file permissions

wp-config.php should be readable by the web server but inaccessible to other users. The recommendation is 600 (only the owner may read/write) or 640 if the web server group needs read access:

# Only owner reads and writes
chmod 600 wp-config.php

# Alternatively, if the web server group must read
chmod 640 wp-config.php

Never set 777 or 666 – that lets any user on the system read the file and extract the database credentials.

Step 3: Block direct HTTP access

Normally wp-config.php is executed as PHP and produces no output. If PHP processing fails, however (misconfiguration, server migration), the plain text content could be served. Block direct access additionally at the web server level.

Apache (.htaccess)

<Files wp-config.php>
    Require all denied
</Files>

nginx

location = /wp-config.php {
    deny all;
    return 403;
}

Step 4: Add hardening constants

In wp-config.php, above the line /* That's all, stop editing! */, add the following constants:

// Disable the file editor in the admin area (prevents editing
// theme and plugin code via wp-admin)
define( 'DISALLOW_FILE_EDIT', true );

// Optional: completely prevent installing/updating plugins and
// themes via the dashboard (strictest variant)
// define( 'DISALLOW_FILE_MODS', true );

// Disable debug output in production
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );

// Enforce encrypted connections in the admin area only
define( 'FORCE_SSL_ADMIN', true );

// Limit automatic core updates to security releases
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

DISALLOW_FILE_EDIT is especially important: without this constant, an attacker who takes over an admin account can run arbitrary PHP code directly via Appearance » Theme Editor.

Optional: Move wp-config.php outside the webroot

WordPress also looks for wp-config.php one directory level above the webroot. If your WordPress lives under /var/www/html/, you can move the file to /var/www/wp-config.php. It then sits outside the area reachable via HTTP.

Caution: This only works reliably on classic single site setups with a dedicated webroot. On shared hosting, where several sites share the same parent level, moving it can cause conflicts. When in doubt, check with your host.

How do I verify the hardening works?

Open https://your-domain.com/wp-config.php in the browser. Expected: an empty page (PHP execution) or 403 Forbidden (access blocked) – never readable PHP source code.

Via terminal:

curl -s -o /dev/null -w "%{http_code}\n" https://your-domain.com/wp-config.php
# Expected: 403 (with an active block) or 200 with an empty body

Check permissions:

ls -l wp-config.php
# Expected: -rw------- (600) or -rw-r----- (640)

In the admin area, confirm that no editor appears under Appearance and Plugins anymore (effect of DISALLOW_FILE_EDIT).

Common mistakes

Permissions too strict: On some hosts PHP does not run as the file owner. In that case 600 can cause a 500 error – use 640 or 644 instead.
Keys replaced without a backup: Back up the file before making changes. A typo in the constants takes the site down.
DISALLOW_FILE_MODS too early: This constant also blocks regular plugin/theme updates via the dashboard. Only set it if updates run exclusively via deployment/WP-CLI.
File moved but path wrong: When moving it outside the webroot, do not craft a custom require loader that exposes an absolute server path.

Frequently asked questions (FAQ)

Which file permission should wp-config.php have?

600 is recommended (only the owner may read and write). If PHP does not run as the file owner on your host but through the group, use 640. Never set 777 or 666, because then any user on the server can read the database credentials.

What happens if I change the security keys in wp-config.php?

All logged in users are signed out and have to log in again. This is intended and an effective way to invalidate stolen session cookies. The content of the site stays unchanged. Generate fresh values via the official WordPress secret key generator.

What is the DISALLOW_FILE_EDIT constant for?

DISALLOW_FILE_EDIT disables the theme and plugin editor in the WordPress admin area. Without this constant, an attacker who takes over an admin account can run arbitrary PHP code directly through Appearance » Theme Editor. The constant is therefore one of the most important hardening measures.

Should I move wp-config.php outside the webroot?

WordPress also looks for wp-config.php one directory level above the webroot. On classic single site setups with a dedicated webroot, moving it increases security. On shared hosting, where several sites share the same parent level, it can cause conflicts – when in doubt, check with your host.

How does InspectWP help with wp-config.php?

During the crawl, InspectWP checks among other things whether sensitive files such as wp-config.php or a wp-config.php.bak backup are publicly reachable, whether the admin area is enforced over HTTPS and whether debug output leaks to the outside. Corresponding findings are flagged as a security risk in the report.