Every WordPress site has one file that holds the keys to everything else: wp-config.php. You probably have never opened it. Your host or developer created it during installation, and it has sat quietly in the site’s main folder ever since.
That quiet is the problem. Because nobody looks at it, nobody notices when it is readable by the wrong people, when a backup copy of it is sitting next to it, or when it was pushed to a public code repository years ago. Here is what the file contains, why attackers go looking for it, and the practical steps that keep it out of their hands.
What wp-config.php actually holds
WordPress reads this file on every page load. It tells WordPress how to reach its database and how to behave. The important parts are:
- Database credentials. The database name, username, password and host. With these, someone can read or change every post, page, user account and order on your site.
- Authentication keys and salts. A set of long random strings WordPress uses to secure login cookies. They are the reason a stolen cookie cannot simply be forged from scratch.
- The table prefix. The short label in front of every database table name, often wp_ by default.
- Debug settings. Whether WordPress shows or logs PHP errors, and where.
Why attackers want it
Under normal conditions, nobody can read wp-config.php from a browser. The server runs it as PHP, and PHP returns nothing visible. Attackers know this, so they look for the situations where that protection fails.
If they get the database password, they may be able to connect to the database directly, depending on how the host is set up, or use it from another compromised account on the same server. They can then create a new administrator, plant spam links, or copy customer data. If they get the salts, they have one of the ingredients for forging login cookies. And if the password in the file is reused anywhere else, such as your hosting panel or email, the damage spreads well beyond WordPress.
That is why a cleanup after a hack always includes this file. Our guide on how to fix a hacked WordPress website covers the full sequence. This post is about stopping it getting that far.
Practical ways to protect it
1. Set tight file permissions
File permissions decide who on the server can read or change a file. wp-config.php should be readable by the account that runs your site and nobody else. On many hosts that means a setting such as 600 or 640, and some setups use 440 or 400, which also stops the file being changed. What matters most is that it is never world-readable or world-writable, which is what 644 or 666 would allow on a shared server.
The right value depends on how your host runs PHP, so check with them before changing it. If the site shows an error straight after you tighten permissions, PHP can no longer read the file, and you need a slightly looser setting rather than the strictest one.
2. Deny web access to the file
This is a second layer for the day PHP stops working properly, for example after a broken server update, when a server might send the file as plain text instead of running it.
On Apache or LiteSpeed hosting, you add a short rule to the .htaccess file in your site’s root that refuses any request for wp-config.php. On current Apache versions the rule wraps Require all denied inside a <Files wp-config.php> block. On nginx, there is no .htaccess, so the equivalent goes in the server configuration as a location block matching wp-config.php with deny all; inside it. On managed hosting you may need to ask support to add it.
After adding either rule, visit yourdomain.com/wp-config.php in a browser. You should get a “403 Forbidden” error, not a blank page.
3. Move it one directory above the web root
WordPress has a built-in feature here. If it cannot find wp-config.php in its own folder, it checks the folder one level up. So if your site lives in public_html, you can move the file into the folder that contains public_html, where the web server cannot serve it at all.
There are two caveats. It only works one level up, not further. And it only works if that parent folder does not hold its own separate WordPress installation. On some hosts the parent folder is shared between several sites, which makes this less tidy. Treat it as a useful extra, not a substitute for the steps above.
4. Change the salts after any hack
If you think the site has been compromised, replace the keys and salts. WordPress provides an official generator at api.wordpress.org/secret-key/1.1/salt/, which gives you a fresh set each time you load it. Paste the new lines over the old ones in wp-config.php.
The effect is immediate: every logged-in user, including any attacker holding a stolen cookie, is logged out. That is the point. Do this together with changing every administrator password and the database password, otherwise the attacker can simply log back in.
5. Turn off error display on the live site
Developers often switch on WP_DEBUG while fixing a problem and forget to switch it off. With debug display on, PHP errors appear on the page for every visitor, and those messages can reveal folder paths, plugin names and other details that help an attacker map your site.
On a live site, WP_DEBUG_DISPLAY should be false. If you need a log, WP_DEBUG_LOG writes errors to a file instead. Be aware that by default that file is wp-content/debug.log, which a browser can often download. Either point the log somewhere outside the web root, block it the same way as wp-config.php, or delete it once you have finished. Better still, do your debugging on a staging site.
6. Disable the built-in file editor
The WordPress dashboard includes editors for theme and plugin code. If anyone gets into an administrator account, those editors let them insert malicious code in seconds. Adding the line that sets DISALLOW_FILE_EDIT to true in wp-config.php removes them. Business sites rarely need them, and code changes are safer made through proper file access with a backup in place.
7. Never leave copies in the web root
This one causes more exposure than any other. Someone edits wp-config.php over FTP and saves a safety copy called wp-config.php.bak, wp-config.old or wp-config.php.save. Some text editors leave their own hidden copies too, often ending in a tilde or .swp.
The server only runs files ending in .php as PHP. A file ending in .bak is just text, so a browser can download it, credentials and all. Automated scanners request these names constantly. Look through your site’s root folder now, and delete anything that looks like a copy. If you need a backup of the file, keep it on your own computer or in a proper off-site WordPress backup, never on the public part of the server.
8. Keep it out of public git repositories
If your site’s code is kept in Git, wp-config.php should be listed in the repository’s .gitignore file so it is never committed. A file pushed to a public repository on GitHub or elsewhere can be found and copied, and deleting it later does not remove it from the repository’s history. If that has already happened, assume the database password and salts are known: change them, and treat it as a possible breach.
This is worth checking when you take over a website from another developer. Ask where the code is stored and who can see it.
A quick check you can do today
- Visit yourdomain.com/wp-config.php and confirm you get a “403 Forbidden” error. A blank page means PHP ran the file but the deny rule is not working; readable text means the file is exposed.
- Ask your host what permissions the file has.
- Look for .bak, .old or .save copies in the root folder and delete them.
- Confirm errors are not shown on your live pages.
- Check whether DISALLOW_FILE_EDIT is set.
If you would rather have someone check this file and the rest of your site’s setup for you, our website security maintenance service includes this kind of hardening, and we will explain what we change and why before we touch anything.
Next in this series: WordPress User Roles: Give Each Person Only What They Need
