WordPress security hardening: the settings that actually move the needle

There are two kinds of WordPress security work. One is loud and reactive: a firewall watching traffic, something hunting for trouble after it arrives. The other is quiet and preventative: closing the doors that should never have been open in the first place. The second kind is called hardening, and it is the part most sites skip, because none of it feels urgent until the day it does.

Hardening is unglamorous on purpose. It does not catch an attack in progress; it removes the easy footholds an attacker looks for before they bother trying anything clever. The good news is that most of those footholds are a single setting away from closed. This is a guide to the ones worth closing first, why each matters, and which you can fix in seconds versus which need a human decision.

Hardening is not a firewall, and that is fine

It is worth being clear about what hardening is and is not, because the security plugins tend to blur the line. A firewall inspects requests in real time and blocks the ones that look malicious. Hardening does something different and complementary: it shrinks the attack surface so there is less for a firewall to defend. Turning off an unused protocol, hiding the information an attacker would use to fingerprint your site, refusing to confirm valid usernames. None of that blocks a request. It just means the request finds nothing useful to work with.

RecapWP lives firmly on the hardening side. It does not claim to be a firewall, it does not watch traffic, and it makes no promise of real-time protection. What it does is find the exposures and, where the remedy is a known configuration change, apply it for you. Run it alongside a security plugin, not instead of one.

The exposures worth closing first

These are the findings that show up on almost every unhardened WordPress site. Each is low-effort to close, and most carry a one-click fix that writes the change for you.

XML-RPC open to the public

XML-RPC is a legacy remote-access endpoint that most modern sites never use, yet it ships enabled. Left open, it is a favorite target for brute-force and amplification attacks, because it lets an attacker try many credentials in a single request. Unless you have a specific app or service that needs it, it should be closed.

Usernames that can be enumerated

WordPress will, by default, happily confirm whether a username exists, through author archive URLs and the REST API. That hands an attacker the first half of every login attempt for free. Blocking enumeration means a brute-force tool has to guess the username and the password, instead of just the password.

The WordPress version on display

Your WordPress version sits in the page source and the feed by default. On its own it is harmless. The moment a vulnerability is disclosed for a specific version, it becomes a targeting list, and automated scanners read it before you have finished your coffee. Removing the version disclosure is pure upside.

Missing security headers

A handful of HTTP response headers tell the browser how to behave: do not let this page be framed by another site, do not guess content types, set a sensible referrer policy. Most WordPress installs send none of them. Adding them is invisible to visitors and quietly closes a category of clickjacking and content-type attacks.

Browsable folders and stray install files

If your uploads directory lists its contents to anyone who visits the URL, that is information you did not mean to publish. The same goes for the install files WordPress leaves behind, like readme.html and license.txt, which conveniently state your version. Both are quick to lock down.

What RecapWP does here: every exposure above is a deterministic configuration change, so it carries a one-click fix that applies the setting right where the finding is, and records it so you can reverse it later if you ever need to. No guessing about what to change.

Logins: the door everyone tries

If there is one part of your site under constant, automated pressure, it is the login form. Two settings make a real difference.

The first is limiting failed logins. Out of the box, WordPress will let a script try passwords as fast as it can connect. A failed-login limit slows that to a crawl and makes large-scale guessing impractical. RecapWP can turn on a built-in limiter for you. It also watches for a failed-login spike and surfaces it as a finding, so a brute-force attempt in progress does not go unnoticed.

The second is making sure the site actually runs on HTTPS, and that the certificate is not about to expire. Both are flagged rather than applied for you, because moving a site to HTTPS or renewing a certificate is an infrastructure decision that belongs with you and your host, not a setting a plugin should silently flip.

A finding that only tells you something is wrong has done half the job. The half that matters is the one that closes it.

The ones you fix by hand

Not every hardening item should be automated, and a tool that pretends otherwise is one to be wary of. Some findings are deliberately detect-only, surfaced with guidance rather than a button.

Security keys and salts left at their placeholder values, a database still using the default wp_ table prefix, a core file that has been modified. Each of these can break a site if changed carelessly, or depends on your host and environment, so the right move is to show you the problem clearly and let you decide what to do. The value is in the finding: most site owners never knew the issue was there.

Determinism, and an undo

Two things make a hardening pass trustworthy. The first is that it is deterministic. Every check is a rule, not a judgment call, so the same site returns the same findings every time, and no model is in the loop deciding whether your XML-RPC is exposed. The code knows; it does not guess. The second is that every change it makes is reversible, recorded in an apply-and-undo ledger you can roll back one fix at a time or all at once. Hardening should never be a one-way door.

Make it a pass you repeat

Hardening is not a one-time event, because the things that drift do so quietly: a reactivated XML-RPC, a plugin that adds a header you did not want, a setting flipped during a migration. The fix is the same as it is for the rest of site health. Run the scan on a schedule, read the security findings worst-first, apply the configuration fixes, and put the handful of judgment calls on your list. Fifteen minutes, and the easy doors are shut.

None of this replaces a firewall, a backup, or good passwords. It sits underneath all of them, removing the obvious exposures so the rest of your security stack has less to do. The fastest way to see which doors are open on your own site is to run a scan and look.