How to secure wp-config.php

wp-config.php is the most sensitive file in a WordPress install. It holds the database name, username, password and host in plain text, along with the authentication keys and salts WordPress uses to sign login cookies. Anyone who can read it can read your entire database. It deserves tighter protection than the standard 644 and 755 scheme applied to everything else.

Tighten its permissions

The default is usually 644, which lets every user on the server read the file. On shared hosting, "every user" is not a hypothetical. Set it tighter:

• 600 (owner reads and writes) is the strictest common choice. chmod 600 wp-config.php
• 640 (owner reads and writes, group reads) is needed on some hosts where the web server runs as the file's group rather than its owner.
• 440 or 400 (read-only) also works, and stops the file being edited by accident or by a script. You then need to loosen it briefly when you edit.

The test is simple: set the strictest value, then load the site. If it shows a database error or a blank page, PHP could not read the file, so step up to 640. Do not jump to 777, which makes the file writable by anyone. The file permissions guide covers the rest of the site.

Move it above the web root

WordPress looks for wp-config.php in its own folder first, then one folder above. If you move the file up one level, it is no longer inside the directory the web server publishes. Even if a server misconfiguration ever served PHP source as text instead of running it, the file would not be there to find.

This works when WordPress sits in the web root and nothing else in the parent folder is a WordPress install. A few restrictive shared hosts block access outside the web root, in which case leave it in place and rely on permissions and the server rule below.

Block direct requests at the web server

On Apache, a rule in .htaccess can refuse any request for the file by URL. Add this near the top of the file in your site root:

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

On Nginx, the equivalent is a location = /wp-config.php block that returns a 404 or denies the request. Your host's support can add it if you do not manage the server config.

Rotate the secret keys after an incident

The file also contains eight authentication keys and salts. WordPress uses them to sign login cookies. If you suspect someone had access, generate a new set and replace the old values. Every existing session is then invalidated, logging out anyone holding a stolen cookie, without anyone needing to change a password. With WP-CLI it is one command: wp config shuffle-salts. Otherwise use the official WordPress secret-key generator and paste the result in.

A few safe settings to add

• Turn off the built-in file editor. define( 'DISALLOW_FILE_EDIT', true ); removes the theme and plugin editors from wp-admin, so a stolen admin login cannot be used to edit PHP in the browser.
• Keep debug output off in production. WP_DEBUG should be false on a live site. If you need logging, send it to a file with WP_DEBUG_LOG and set WP_DEBUG_DISPLAY to false, because on-screen errors can reveal file paths.
• Force HTTPS for logins. define( 'FORCE_SSL_ADMIN', true ); keeps the admin area and login on HTTPS.
• Give the database user only what it needs. It should have access to this site's database and nothing else, and its password should be unique, as the security checklist advises.

How to test it

Request the file the way an outsider would. Run curl -I https://yoursite.example/wp-config.php. You want a 403 or 404, or a 200 with an empty body (PHP ran and printed nothing). If you ever see the file's text, stop and rotate your database password and secret keys immediately. Then check the file's permissions with ls -l wp-config.php and confirm the site still loads.

What not to do

Do not loosen the file's permissions to "fix" a plugin that says it cannot read the file. That is almost always a problem elsewhere, and 777 on the file holding your database password is one of the worst places to make a mistake. Do not leave copies in public folders either. A forgotten wp-config.php.bak or wp-config.old in the site root or in uploads/ is a common way this file leaks, because the server hands those out as plain text. Delete backups or keep them outside the web root.