Imagine waking up to find your WordPress site redirecting visitors to a spam page — and your own admin password no longer works. In many such mornings, the break-in traces back to one overlooked file: wp-config.php. Learning how to secure wp-config.php is not server wizardry. It is a 30-minute job that can mean the difference between a scare and a full site takeover.
Here is the uncomfortable truth: this one file holds your database password and the secret keys protecting every login on your site. If an attacker reads it, they often do not need your password at all. A handful of simple steps can lock it down hard.
Why Learning How to Secure wp-config.php Matters So Much
The wp-config.php file sits in the root folder of every WordPress installation. WordPress reads it first, because it needs the database connection details inside: database name, username, password, and host — plus eight secret values (four keys and four salts) that sign login cookies.
Key takeaway: whoever holds this file holds the keys to your entire site. With the database credentials, an attacker can read or change every post, user, and setting. With the keys and salts, they can potentially forge login cookies and impersonate accounts, including yours.
Normally, visitors cannot read the file by typing yoursite.com/wp-config.php into a browser — the server runs the PHP code and returns a blank page. The danger comes from mistakes around it: a backup copy left in a public folder, loose permissions, a server misconfiguration, or a stray copy in a public code repository. That is why wp-config.php security deserves attention before something goes wrong, not after.
Back up your site (files and database) before you start — every step below is low-risk, but a backup turns any mistake into a five-minute fix.
How to Secure wp-config.php in 7 Steps
Step 1: Move wp-config.php Above the Web Root
This is the single most powerful move available, and it costs nothing. WordPress automatically looks for wp-config.php one directory above your installation folder if it does not find it in the root. So if your site lives in public_html, move the file to the folder just above it. WordPress will still find it, but no web request can ever reach it — because the web server only serves files inside the public folder.
A real-world example: a small business owner migrates her site, and her developer leaves a config copy in the site root “just in case.” Months later, a server glitch briefly serves its contents as plain text to anyone who asks. Above the web root, that glitch would have been harmless. (If your host offers no folder outside the web root, steps 2 and 3 are your main defense.)
Step 2: Lock Down wp-config.php File Permissions
File permissions decide who on the server can read or change a file. For most WordPress files, 644 is standard. For wp-config.php, go stricter: wp-config.php file permissions 600 (owner only) is the recommended setting on most hosts. If 600 breaks your site, use 440 instead (owner and group can read, nobody can write).
Set this in cPanel’s File Manager (right-click → Permissions) or over SSH: chmod 600 /path/to/your-site/wp-config.php. Never use 777 on a live site — it lets anyone on the server read and modify the file.
Step 3: Block Direct Web Access with a Server Rule
Add an explicit server rule that refuses any web request for the file. This is your second layer: if PHP processing ever fails, the server still will not hand the file out. On Apache or LiteSpeed hosts, add this to the .htaccess file in your WordPress root, outside the # BEGIN WordPress block:
<Files wp-config.php>
Order allow,deny
Deny from all
</Files>
Then test it: visiting yoursite.com/wp-config.php should return a 403 Forbidden error, not file contents. (On Nginx, use an equivalent location block.)
Step 4: Delete Stray Backup Copies of the File
This mistake catches even careful site owners. Editing and migration tools often leave copies named wp-config.php.bak, wp-config.php.old, or wp-config.php~. Unlike the real file, these are usually served as plain text — so anyone guessing the filename can read your database password in their browser.
Search your site root and backup folders for these names and delete every copy. Also make sure backup archives live outside the public folder or behind password protection — never as downloadable files in wp-content/uploads.
Step 5: Rotate Your WordPress Security Keys and Salts
Your file holds eight secret values: four keys and four matching salts. These sign the cookies that keep users logged in. If they were ever exposed — or you inherited a site with unknown history — replacing them instantly invalidates every existing login cookie and session.
Fresh values are free from WordPress’s official generator. Copy the output, replace the old eight lines, and save. Everyone will need to log in again — which is exactly the point: any stolen cookie becomes useless. Make WordPress security keys and salts rotation routine after any security scare.
Step 6: Disable File Editing from the Dashboard
By default, WordPress lets administrators edit theme and plugin code from inside the dashboard under Appearance → Theme File Editor. That means anyone who steals an admin login can inject malicious code without ever touching your server. Close that door by adding this line to wp-config.php, above the line that says “That’s all, stop editing!”:
define('DISALLOW_FILE_EDIT', true);
To disable file editing in WordPress wp-config completely, including dashboard installs, use define('DISALLOW_FILE_MODS', true); instead — only if you install everything via SFTP.
Step 7: Force SSL for Admin and Turn Debug Mode Off
Two final lines round out your hardening. First, force admin over HTTPS (only after confirming your site fully works over HTTPS):
define('FORCE_SSL_ADMIN', true);
Second, keep debug mode off on a live site, since error messages can leak paths and database details: define('WP_DEBUG', false);.
wp-config.php Security Methods Compared
| Method | What it stops | Difficulty |
|---|---|---|
| Move above web root | Direct web access, even if PHP fails | Easy, if host allows |
| Permissions 600 or 440 | Other server users reading it | Easy |
| .htaccess deny rule | Browser requests reaching the file | Easy |
| Delete .bak / .old copies | Plain-text copies leaking credentials | Easy |
| Rotate keys and salts | Stolen login cookies staying valid | Easy |
| DISALLOW_FILE_EDIT | Stolen admin logins becoming code injection | Easy |
| FORCE_SSL_ADMIN, WP_DEBUG off | Cookie interception, error leaks | Easy |
What to Do If wp-config.php Was Already Exposed
If you suspect the file was ever readable by outsiders, treat it as compromised. First, change your database password in your hosting panel, then update DB_PASSWORD to match. Second, rotate all eight keys and salts — this logs everyone out and kills stolen sessions. Third, change your WordPress admin, hosting, and SFTP passwords. Fourth, scan for unknown admin users, unfamiliar plugins, and recently modified files. If you find signs of a break-in, restore from a clean pre-exposure backup, then reapply the seven steps.
For a recovery walkthrough, see how to check if your WordPress site is hacked. If login attacks worry you, see how to protect WordPress from brute force attacks. Prefer professional help? See our services or contact us.
Frequently Asked Questions
Can I move wp-config.php above the web root on shared hosting?
In most cases, yes. Shared hosts typically give you a home folder one level above public_html, and WordPress checks it automatically. If not, rely on strict permissions and the .htaccess deny rule.
What file permissions should wp-config.php have?
Use 600 where possible: only the file owner can read and write it. If that breaks your site, use 440 instead. Avoid 644 for this file, and never use 777 on a live site.
Is it safe to edit wp-config.php directly?
Yes, if you back the file up first and use a plain-text editor or your host’s file manager — never a word processor. Add settings above the “That’s all, stop editing!” line, save, and reload your site to confirm it works.
How often should I rotate my WordPress security keys and salts?
Rotate them after any suspected exposure, a site handover, or removing a user with server access. Refreshing them every few months is also sensible hygiene.
Conclusion: Secure wp-config.php Today, Not After the Breach
You now know how to secure wp-config.php: move it above the web root, lock permissions to 600, block web access, delete stray copies, rotate keys and salts, disable dashboard editing, and force SSL with debug mode off. Seven steps, thirty minutes, no paid tools.
Here is the punchy truth: attackers rarely break into WordPress sites with genius hacks — they walk through doors site owners left unlocked. Close this one today, while it is still your choice — not tomorrow, when it is damage control.
