Harden wp-config and .htaccess the Right Way

Harden wp-config and .htaccess the Right Way

You probably landed here because something felt off — maybe Wordfence threw a warning, maybe your host flagged unusual traffic, or maybe you just Googled “how do I actually lock down my WordPress site” after reading one too many horror stories. Either way, good instinct. The two files I’m going to walk you through — wp-config.php and .htaccess — are the first things I check on every site I work on, and the most commonly misconfigured ones I see.

I’ve been cleaning hacked WordPress sites since 2011. Pharma hacks, redirect malware, base64-encoded junk buried in wp-content/uploads — I’ve seen all of it. And honestly, a surprising number of those infections could have been slowed down or stopped entirely if the site owner had spent 20 minutes on these two files before the attack happened.

What wp-config.php Actually Exposes (And What to Do About It)

This file holds your database credentials, your secret keys, and your table prefix. If someone reads it — really reads it, not just sees the PHP output — they own your database. That’s not an exaggeration.

The first wp-config security tweak I make on any new site is moving the file one level above the WordPress root. So if your site lives at /public_html/, I move wp-config.php to /public_html/../wp-config.php — effectively /wp-config.php one directory up. WordPress looks there automatically. Most shared hosts allow this. It won’t solve every problem, but it means a directory traversal attempt that reaches public_html doesn’t immediately land on your credentials.

Next — change your table prefix. The default is wp_ and every automated SQL injection script on the planet knows that. If you’re setting up a new site, just change it during install. If the site is live, it’s a bit more involved, but it’s doable with a plugin like Brozzme DB Prefix or a careful manual SQL run. I’ve done it dozens of times on live sites without downtime.

Then there are the security keys. If yours look like placeholders or haven’t been rotated in years, generate fresh ones from the official WordPress salt generator and paste them in. Takes two minutes. Invalidates all existing sessions immediately — which is exactly what you want if you suspect any unauthorised access.

One thing I always add — and this is non-negotiable for me — is disabling the file editor from within WordPress itself. This is the setting that lets logged-in admins edit plugin and theme PHP directly from the dashboard. It’s convenient. It’s also a gift to any attacker who gets hold of an admin password.

// Add this to wp-config.php
define( 'DISALLOW_FILE_EDIT', true );

One line. Done. This is the single most impactful wordpress hardening checklist item that people skip because it sounds minor. It isn’t.

The .htaccess Rules That Actually Matter

Most WordPress sites have a default .htaccess that does exactly one job: route requests through WordPress. That’s fine as a starting point. But there’s a lot more you can do in there, and the rules I’m about to share are ones I’ve used on real client sites — some of them e-commerce stores doing $30,000+ a month in revenue where the owners were genuinely nervous about downtime.

First — protect wp-config.php directly at the server level. Even if it’s been moved up a directory, add this:

<files wp-config.php>
order allow,deny
deny from all
</files>

No visitor, no bot, no scanner should ever be able to request that file. Apache will return a 403. Done.

Next, block direct access to .htaccess itself and to xmlrpc.php if you’re not using it (and most sites aren’t, even if they think they need it for Jetpack — Jetpack has worked fine without full xmlrpc access since 2020).

You should also be blocking execution of PHP files inside wp-content/uploads. I can’t stress this enough. This is how attackers plant webshells — they upload a disguised PHP file through a vulnerable plugin’s uploader, then execute it directly. The fix in .htaccess is straightforward:

<Directory "/public_html/wp-content/uploads">
<Files "*.php">
Order Deny,Allow
Deny from All
</Files>
</Directory>

Put that in the uploads directory’s own .htaccess file, not the root one. I’ve seen this single rule prevent re-infection on sites I’ve cleaned — which is something I wrote about in more detail in my post on how to remove malware from WordPress manually.

My Honest Opinion on Security Plugins vs. Manual Rules

Here’s where I’ll give you a straight answer instead of a neutral “it depends.” Security plugins like Wordfence are genuinely useful — I use them, I recommend them, they catch things I’d miss during a quick scan. But I do not rely on them as a substitute for proper htaccess security rules and a hardened config file. They are layered on top, not instead of.

Wordfence’s firewall, for instance, loads as a WordPress plugin. That means it fires after PHP has already started. A well-written .htaccess rule blocks the request before PHP even wakes up. That’s a meaningful difference at the server level. If you’re choosing between a security plugin and proper file hardening, do the file hardening first. Every time.

I’ve taken over sites where the previous developer had Wordfence Premium running but had never touched wp-config.php beyond the default install and left the file editor enabled. One compromised admin account later, the attacker just… edited the theme’s functions.php from inside the dashboard. No scanner catches that in real time. If you want to understand how quickly things spiral after that point, have a read through what to do immediately after your WordPress site gets hacked.

A Quick Sanity Checklist Before You Close This Tab

Run through these. Shouldn’t take more than 30 minutes on a site you know well.

• DISALLOW_FILE_EDIT set to true in wp-config.php
• Table prefix changed from the default wp_
• Secret keys rotated recently (within the last 12 months is fine)
• wp-config.php blocked via .htaccess
• PHP execution blocked in the uploads folder
• xmlrpc.php access restricted or blocked if unused
• WordPress core auto-updates enabled (or at minimum, you’re updating within a week of releases)

None of this is exotic. None of it costs money. It’s just the baseline that too many sites are missing when I first look at them.

The htaccess security rules I add before anything else

Every time I crack open a client’s .htaccess after a cleanup, I find the same thing: either it’s completely bare or it’s stuffed with plugin-generated garbage that contradicts itself. My htaccess security rules go in at the very top, before the WordPress rewrite block, because order matters and most people don’t realize that. I block direct access to wp-config.php, disable directory browsing, and kill script execution inside uploads — that last one alone would’ve stopped about a third of the PHP backdoors I’ve pulled from sites over the years. Get the order wrong and Apache just ignores half of it.

If you’d rather have someone go through this properly — or if you’re staring at a site that’s already been compromised — I take on this kind of work at swsDreams. I can usually turn around a security audit or a hardening job within 24–48 hours depending on timezone.