How to Secure wp-config.php: The Complete Guide

Table of contents12

The phone call I remember most from my early days managing WordPress sites was not about a hacked homepage or a defaced blog. It was quieter than that. A client’s online store had started showing a database connection error, and when I opened their wp-config.php file to check the credentials, I noticed the file permissions were set to 644 on a crowded shared server. That meant any other customer on that same server could read the file — and with it, the database username and password. Nobody had defaced anything. Nobody had sent a ransom note. The keys to the entire site were just sitting there in the open, and nobody had noticed. That day I learned the hard way why every serious guide on how to secure wp-config.php in WordPress starts with file permissions.

I’m Aisha Khan, and I have spent years hardening WordPress sites for small businesses that cannot afford a security team. The lesson that phone call taught me still shapes every site I touch: attackers don’t always break in through the front door. Sometimes they just pick up the keys you left lying around. Your wp-config.php file is exactly that — the keys to everything. If you want to secure wp-config.php, WordPress actually gives you everything you need. You just have to know where to look.

Here is the fear I want to name plainly, because it is real: if someone reads your wp-config.php file, they get your database credentials, your secret keys, and enough information to take over your entire site. Not deface it. Own it. And the scary part is that most site owners never look at this file until something is already wrong.

In this guide I will walk you through the exact seven-step process I use to secure wp-config.php on every site I manage: backing up first, moving the file above the web root, locking down permissions, blocking browser access, rotating your security keys, disabling the built-in file editor, and cleaning up the loose ends most people forget. This guide is for site owners who manage their own WordPress installation and want to do it properly, without installing anything new. Ready? Let’s get started.

One honest note before we begin: a single typo in wp-config.php will take your entire site down with a white screen. That sounds scary, but every step in this guide is reversible as long as you keep a backup copy of the original file. I have broken sites with typos more times than I care to admit, and the backup is what saved me every single time.

What You Will Learn in This Guide

• What the wp-config.php file actually holds, and why attackers want it so badly
• How to move the file above the web root so browsers can never reach it
• Which file permissions to use (and what the numbers 400, 440, and 600 really mean)
• How to block direct access to the file at the server level
• How to generate fresh security keys and salts the right way
• How to disable file editing in the WordPress dashboard
• The cleanup steps almost everyone skips — debug mode and stray backup copies

Ready? Let’s get started.

What This One File Actually Holds (and Why You Must Secure wp-config.php in WordPress)

Every WordPress installation has exactly one wp-config.php file sitting in its root folder. It is created during installation, and after that most people never open it again. That is a mistake, because this single file holds the four most sensitive pieces of information on your entire site: your database name, your database username, your database password, and the host your database runs on.

Think of it this way. Your WordPress site is a house. The database is the safe inside the house. And wp-config.php is a sticky note on the front door with the safe’s combination written on it. If an attacker can read that file, they don’t need to guess anything or exploit anything clever. They can connect straight to your database and read, change, or delete everything — posts, user accounts, passwords, all of it.

The file also holds your authentication keys and salts — long random strings WordPress uses to encrypt login cookies. If those leak, an attacker can potentially forge login sessions. Security researchers who clean up hacked sites report again and again that a stolen wp-config.php is one of the fastest routes to a full site takeover. It is genuinely the crown jewel of your WordPress installation, and it deserves to be treated that way.

Here is the part that surprised me when I first learned it: under normal conditions, nobody can read this file through a browser, because the server processes it as PHP code and returns nothing. The danger comes from the abnormal conditions — a misconfigured server, a backup copy saved with a .bak extension that the server serves as plain text, or a shared hosting neighbor reading it straight off the disk. Each step in this guide closes one of those abnormal conditions. Let’s close them all.

Step 0: Back Up the File Before You Touch Anything

I am putting this as Step 0 because everything else depends on it. Before you change a single character in wp-config.php, download a copy to your own computer. Use your hosting file manager or an FTP client, find wp-config.php in your site’s root folder, and download it. Name the copy something clear like wp-config-backup-2026-10-18.php and store it somewhere safe — not in a public folder of your website.

Why am I so insistent about this? Because PHP is unforgiving. One missing semicolon, one misplaced quote mark, and your entire site shows a white screen — not just one page, every page. I learned this the hard way years ago when I edited the file directly on a live site at midnight and typed a curly quote instead of a straight one. The site went down, and I spent a panicked hour fixing it. With a backup copy on your computer, recovery takes thirty seconds: you just upload the original file back.

While you are at it, confirm you have a full site backup too — files plus database. If you do not have a backup routine yet, read our WordPress file permissions security guide to understand how file access works on your server, and set up regular backups before making security changes. A backup you cannot restore is not a backup, so this is also a good moment to verify that your last backup actually completed.

Step 1: Move wp-config.php Above the Web Root

This is the single most effective thing you can do to secure wp-config.php in WordPress, and it takes about two minutes. Your website lives in a folder like public_html or www — that is your web root, the folder the browser can reach. Everything inside it can potentially be served over HTTP. If you move wp-config.php one level above that folder, no browser request can ever reach it, no matter what goes wrong with your server configuration.

The beautiful part is that WordPress already expects this. When WordPress loads, it looks for wp-config.php in its own folder first, and if it does not find it there, it automatically checks one directory above. This is official, documented behavior — not a hack. So you simply move the file up one level, and WordPress finds it on its own.

Here is how to do it with your hosting file manager. Open the file manager in your hosting control panel and navigate to your web root — the folder containing wp-admin, wp-content, and wp-includes. Select wp-config.php, choose Move, and move it to the parent folder, one level up. Then visit your website. If the site loads normally, you are done. If you see a database connection error, just move the file back and try the next step instead — some hosting setups do not allow this, and that is fine.

Let me be honest about what this does and does not do. Moving the file does not make it invisible — anyone with file-level access to your server can still see it. What it does is remove an entire class of attacks: no HTTP request, no misconfigured server rule, no clever URL trick can serve a file that is not inside the web root. Think of it as taking the sticky note off the front door and putting it in a locked drawer. The note still exists, but nobody walking past the house can read it anymore.

Step 2: Lock Down the File Permissions

File permissions decide who is allowed to read or change a file on your server. They are expressed as three-digit numbers, and those numbers are the difference between “only you can read this” and “everyone on this server can read this.” This is the step that would have prevented the phone call I told you about at the start.

Here is the plain-English version of the numbers. 400 means only the file’s owner can read it — nobody can change it, not even you, until you loosen the permission. 440 means the owner and the owner’s group can read it. 600 means the owner can read and write it. The default on most servers is 644, which means everyone can read it — and on shared hosting, “everyone” includes the other customers sharing your server. That is how my client’s database password was exposed: not through hacking, just through a readable file.

The recommendation from WordPress security specialists is to set wp-config.php to 400 or 440 if your host supports it, or 600 if your site needs the owner to write to the file. Any of these is a huge improvement over 644. To change it, right-click the file in your hosting file manager, choose Permissions or Change Permissions, and set the number. Or over SSH, run:

chmod 400 wp-config.php

After changing the permission, load your site and log into your dashboard to make sure everything still works. On some hosting setups, 400 is too strict and WordPress needs to write to the file occasionally — if anything breaks, step up to 600. The honest truth is that the “right” number depends on your host, so test it. Never use 777 on this file — that means anyone can read and change it, which is the digital equivalent of taping the safe combination to the front window.

Bonus Tip: permissions matter everywhere, not just on this one file. Directories should be 755 and regular files 644 as a baseline, with wp-config.php as the strict exception. Our complete guide to WordPress file permissions walks through the whole permission model if you want to audit your entire installation.

Step 3: Block Direct Browser Access at the Server Level

Even with the file moved and permissions tightened, defense in depth is the name of the game. This step adds a server-level rule that rejects any browser request for wp-config.php before PHP even gets involved. It is your safety net for the day something else goes wrong.

If your site runs on Apache — which covers most shared hosting — open the .htaccess file in your web root and add this block:

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

If your host still runs the older Apache 2.2 style configuration, use this version instead:

<Files wp-config.php>
    Order allow,deny
    Deny from all
</Files>

If you run Nginx instead of Apache, .htaccess files do nothing — Nginx ignores them completely. Add this to your server block configuration instead:

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

Then reload Nginx for the change to take effect. To verify the block works, try visiting yoursite.com/wp-config.php in a browser. You should get a 403 Forbidden error or a blank page — either means the server refused to serve the file. If you see anything else, double-check where you placed the rule.

Step 4: Generate Fresh Security Keys and Salts

Further down in wp-config.php you will find eight lines defining AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY, and their four SALT companions. These long random strings are what WordPress uses to encrypt login cookies and secure password-related operations. Here is the uncomfortable question: do you know whether yours are actually unique?

Many sites still run with the default placeholder keys from installation, or with keys that were copied from a tutorial, or with the same keys across multiple sites. Some installers generate weak ones. If your keys are not unique and random, they are not doing their job. The fix is simple: WordPress maintains an official secret key generator that produces fresh, cryptographically random keys. Visit it, copy the eight define lines it gives you, and paste them over the existing key block in your wp-config.php — above the “stop editing” comment line.

Note: changing your keys and salts immediately logs out every user on the site, including you. That is not a bug — it is the point. Every existing login cookie becomes invalid, which is exactly what you want if you suspect the old keys were ever exposed. So make this change at a quiet moment, not in the middle of your busiest traffic hour, and warn your team they will need to log in again.

If your host gives you SSH access, there is an even easier way. The WP-CLI command wp config shuffle-salts regenerates all eight keys in place, writes them in the correct location, and cannot introduce a typo. If you are comfortable on the command line, that one command replaces the entire manual process.

How often should you rotate keys? There is no magic schedule, and anyone selling you a strict timetable is guessing. The honest rule: rotate them after any security incident, after anyone with server access leaves your team, and if you ever suspect the file was exposed. Some people do it yearly as hygiene. The important thing is that you know how, so you can do it in minutes when it matters.

Step 5: Switch Off the Built-In File Editor

WordPress ships with a built-in code editor under Appearance and Plugins in the dashboard that lets anyone with admin access edit your theme and plugin PHP files right from the browser. It was designed for convenience. In practice, it is one of the first things an attacker uses after stealing an admin login — they open the Theme File Editor, paste in a backdoor, and they never need FTP access at all.

Cleanup specialists will tell you they have traced reinfections to exactly this path over and over: a compromised admin session, a pasted backdoor through the built-in editor, and the site gets reinfected hours after it was cleaned. Switching the editor off removes that one-click route entirely. Add this line to wp-config.php, above the “stop editing” comment:

define( 'DISALLOW_FILE_EDIT', true );

After saving, the editor menus simply disappear from the dashboard. You can still edit files through FTP or your hosting file manager — you lose nothing except the browser-based convenience that attackers love. If you ever legitimately need the editor back for a quick fix, you can temporarily remove the line, make your change, and put it back. But in years of managing sites, I have needed it maybe twice. The trade is worth it.

There is a stronger version of this setting called DISALLOW_FILE_MODS, which blocks plugin and theme installation and updates from the dashboard entirely. That one is heavy-handed — it means all updates happen through FTP or deployment — so I only recommend it for locked-down sites where changes never happen through the admin panel. For most sites, DISALLOW_FILE_EDIT is the sweet spot.

Step 6: Clean Up Debug Mode and Stray Copies

The final step is the one almost every guide skips, and it is where I have seen real sites get compromised. Two loose ends to check.

First, make sure WP_DEBUG is off on your live site. When debug mode is on, PHP errors display publicly on your pages — and those error messages often reveal server paths, database table names, and plugin details that hand attackers a map of your installation. In wp-config.php, the line should read:

define( 'WP_DEBUG', false );

Second, hunt down stray copies of wp-config.php. Over the years, sites accumulate them: wp-config.php.bak from an old edit, wp-config-backup.php, wp-config.php~ from a text editor, copies left in a migration folder. Here is the danger: your server only processes files ending in .php as PHP code. A file named wp-config.php.bak gets served as plain text — meaning anyone who guesses the URL can read your database password right in their browser. Search your entire site folder for anything starting with wp-config and delete every copy except the one live file. This single cleanup has closed real breaches I have investigated.

Also check that WP_DEBUG_LOG and WP_DEBUG_DISPLAY are not writing a publicly readable debug.log into wp-content. A debug log sitting in your uploads or wp-content folder can leak the same sensitive details as on-screen errors. If you need error logging on production, log it outside the web root.

Bonus Tip: The Two Commands I Run on Every Site

If your host provides SSH access, WP-CLI turns most of this guide into two commands. The first lists every constant currently defined so you can audit your configuration:

wp config list

The second rotates all your security keys and salts safely, with no risk of typos:

wp config shuffle-salts

WP-CLI writes constants in the right place automatically — between the table prefix and the “stop editing” comment — and validates the file’s syntax as it goes. For anyone managing more than one site, learning these two commands pays for itself the first week. And remember the golden rule that applies to every manual edit: never commit wp-config.php to a Git repository. Repositories leak, and production credentials in a leaked repository mean instant compromise.

Secure wp-config.php in WordPress: Frequently Asked Questions

Can someone read my wp-config.php file through a browser? Not normally. Your server processes the file as PHP and returns nothing visible. The risk comes from the abnormal cases: a backup copy with a different extension served as plain text, a server misconfiguration, or another user on the same shared server reading it off the disk. That is exactly what the steps in this guide protect against.

What permissions should wp-config.php have? Set it to 400 or 440 for the strictest sensible protection, or 600 if your host needs the file owner to write to it. Avoid anything that lets other users read the file, and always test that your site still works after the change. Never use 777.

Is it safe to move wp-config.php above the web root? Yes. WordPress officially supports looking one directory above the installation folder, and it finds the file automatically. Test your site and dashboard afterward, and remove the old copy from the web root. The only exception is some managed hosts with custom setups — if the site breaks, just move it back.

How often should I change my security keys and salts? There is no fixed schedule. Change them after any hack or suspected exposure, after someone with server access leaves, and otherwise consider a yearly rotation as hygiene. Each change logs out all users, so pick a quiet moment.

Will disabling the file editor break anything on my site? No. It only removes the Appearance and Plugins code editors from the WordPress dashboard. Your site, themes, and plugins keep working exactly as before. You can still edit files through FTP or your hosting file manager whenever you need to.

Final Thoughts

Learning to secure wp-config.php in WordPress is not glamorous work. Nobody will visit your site and admire your file permissions. But here is what I know after years of cleaning up hacked WordPress sites: the breaches that hurt the most are rarely the sophisticated ones. They are the quiet ones — a readable config file, a stale backup copy, a key that was never rotated. The attacker did not outsmart anyone. They just walked through a door that was left open.

You have just closed those doors. You backed up the file, moved it out of the browser’s reach, locked its permissions, blocked direct access, rotated your keys, switched off the file editor, and cleaned up the stray copies. That is genuinely more than most WordPress sites ever get, and you did it in under an hour with nothing to install.

The honest line: this guide protects the file, but security is a habit, not a project. Pair what you did today with strong admin passwords, regular updates, and a look at our guide to stopping brute-force attacks and our hacked site recovery guide so you know what to do if the worst ever happens. Stay safe out there.

Did any step surprise you — or did you find a stray wp-config backup copy hiding on your server? Tell me in the comments. I read every one.

Published: October 18, 2026 · Updated: October 18, 2026 · By Aisha Khan