Securing wp-config.php: 5 Rules Every Agency Ignores

Nobody wants to talk about WordPress security hardening. It doesn't sell. Clients don't get excited when you tell them you spent four hours locking down their config file. They want the fancy animation on the hero section.

But I'll tell you what's not fancy. Getting an email at 2 AM that says your client's entire WooCommerce database just got dumped to a paste site. I've been on that phone call. It's awful.

I've audited dozens of WordPress sites over the years, sites built by agencies that charge five figures per project. And you know what I keep finding? The wp-config.php file, just sitting there, completely default, totally exposed. This one file has your database credentials, your authentication keys, your table prefix. If someone gets their hands on it, it's game over. They own everything.

So here's what I tell every client, every team, every developer who'll listen.

1. Move wp-config.php Out of the Public Directory

A lot of people don't know this trick, and honestly I didn't either until a few years into my career. WordPress will automatically look one directory above your installation root for the config file.

So if your site lives at /var/www/html/public/, just move wp-config.php up to /var/www/html/. That's it. The file is now physically outside the web-accessible directory. Even if something goes wrong with PHP and your server starts serving raw files as plain text (I've seen this happen on misconfigured Nginx boxes), the config file is safe because the web server can't reach it.

One caveat though. This only works when WordPress sits in the root of your public directory. If you installed it in a subdirectory like /var/www/html/public/wordpress/, moving the config up one level puts it inside the public folder, which defeats the whole point.

2. Fix the File Permissions

This one drives me crazy because it's so simple.

Your wp-config.php should be read-only. Period. Set it to 400 or 440. That means only the file owner (or the web server group at most) can read it. Nobody can write to it.

I can't count how many sites I've seen with this file sitting at 644 or worse, 666. At that point you're basically leaving the front door unlocked with a neon sign that says "come on in."

Run ls -la wp-config.php on your server right now. If it's not 400 or 440, fix it today.

3. Kill the Built-in File Editor

WordPress ships with a code editor that lets admins modify theme and plugin files directly from the dashboard. Sounds convenient, right?

It's a nightmare.

If an attacker compromises a single admin account (through a weak password, a phishing link, whatever), they can open that editor and inject malicious PHP into your theme's functions.php. No SSH access needed. No file manager. Just the WordPress admin panel that you handed them the keys to.

Drop this line into your config file and forget it ever existed:

define( 'DISALLOW_FILE_EDIT', true );

I also recommend adding define( 'DISALLOW_FILE_MODS', true ); on production if you manage deployments through Git or CI/CD. That one blocks plugin and theme installations entirely through the dashboard, which is even more aggressive but honestly, on a production box, nothing should be getting installed through the browser anyway.

4. Change the Default Table Prefix

The default WordPress table prefix is wp_. Every bot, every automated SQL injection script on the internet knows this. They'll blindly target wp_users, wp_options, wp_posts and just start hammering queries.

Changing the prefix to something random like hj83_ or xkr5_ won't stop a targeted attack from a skilled attacker. Let's be real about that. But it absolutely blocks the lazy automated stuff. And honestly, most WordPress attacks are lazy automated stuff.

You can set a custom prefix during installation (the installer asks you right there), or you can change it after the fact with a plugin like Brozzme DB Prefix. Just make sure you back up your database first. I've seen people rename prefixes on a live site without a backup and corrupt their entire user table. Don't be that person.

5. Rotate Your Security Salts

Scroll to the middle of your wp-config.php and you'll find a block of define() statements with long random strings. Those are your authentication keys and salts. They encrypt the cookies that keep your users logged in.

Most people set them once during installation and never touch them again. That's a problem.

If an employee or contractor leaves your organization, or if you even slightly suspect your site was compromised, you need to regenerate those salts immediately. WordPress.org has a secret key generator that spits out fresh ones. Paste them in, save the file, and every single active session gets invalidated. Everyone gets logged out instantly.

Think of it like changing the locks after someone moves out. You wouldn't skip that in real life. Don't skip it on your website either.

The boring stuff is what keeps you safe. Lock down that config file.