Hardening WordPress, in the order that matters

The real order, and why most checklists have the wrong one

A WordPress security checklist usually has thirty items and they all look the same size. In practice they are not. The first three prevent more than the remaining twenty seven, and the order is the thing nobody writes down, because a long list looks more professional.

The order we work through on a client site has six steps, and it is not sorted by ease. It is sorted by how much each one prevents.

Updates first, because most successful break ins to a WordPress site come through a public, already patched vulnerability. Then least privilege, because the size of the damage is set by what the accounts that got in were allowed to do. Then two factor authentication, which turns a leaked password from a disaster into a warning. Then a backup you have restored once, because an untested backup is an assumption, not a copy. Then a security plugin that is still maintained. And last of all, hardening the login page, which is useful and belongs at the end of the list rather than at the front.

The first three steps are entirely in your own hands and none of them costs money. The fourth costs a little and buys the most peace. The fifth and sixth are the ones people usually do first, and they have the smallest effect of the six.

Updates, and why this one prevents more than the rest

When a vulnerability is published, two things are born at the same moment: the description of the problem and the patch for it. From that moment on, anyone who wants to use it knows exactly where to aim, and anyone who has updated is off the list. The whole game is the gap between publication and update.

On this site, from March 2025 until today, the vulnerability scanner has recorded 13 advisories for software installed on this one installation. 10 of them were in plugins, 2 in WordPress core itself and 1 in a theme. By type, seven were cross site scripting, two were broken access control, and the rest were one each: arbitrary code execution, sensitive data exposure, arbitrary file upload and PHP object injection.

Twelve of those thirteen were closed by an update, most of them within days. That number is the one worth looking at: in eighteen months, on a site where nothing dramatic happened, software running on it was declared vulnerable thirteen times and nearly every time the answer was one button.

And now the part that gets said less, and that we ran into ourselves: an update counter reading zero is not proof of being up to date. Commercial plugins update through their own channel, and a lapsed licence makes that counter quiet rather than current. On this installation the counter reads zero and the vulnerability scanner disagrees with it about one item. That is why a vulnerability scanner is needed alongside the update counter; the second sees your installation, the first sees the published list.

We wrote up one recent core example separately: the WordPress 7.0.4 security patch and which servers were actually at risk.

Accounts, and why a site with 1,224 users has exactly one administrator

This site has 1,224 user accounts. One of them is an administrator. The other 1,223 hold roles that cannot install anything, cannot edit a theme file, and cannot see any other user data.

That number is a decision rather than an accident, and the reason is simple: an account that gets compromised hands over exactly what that account could already do. Least privilege is not bureaucracy, it is the size of the blast.

There are two places this rule usually breaks, and both come from good intentions. First, giving an administrator account to a developer or an agency for now, and never removing it; the administrator list on a five year old site usually holds people who stopped working on it three years ago. Second, roles a plugin has added. WordPress adds capabilities up, so a plugin that gives subscribers one new ability has changed your access list and written the news down nowhere.

The next step is two factor authentication, and which method you pick matters. On this site only the authenticator app method is enabled, neither SMS nor email. The reason is that SMS depends on a phone number and a number can be taken from an operator, and email depends on a mailbox that itself opens with a password; if that password is in the same leak, the second factor has stopped being a second factor.

And one point specific to WordPress: application passwords. These are separate passwords created to connect tools, and they go around two factor authentication by design, because they are meant to work without a person. If you have turned two factor on, look at the application password list on that same account as well; otherwise an open door is still standing next to the locked one.

An untested backup is not a backup, and it can leak too

A backup you have never restored is a folder. That sentence sounds like a cliche until the day you need it and find out the file was truncated, or that the password needed to open it lived inside the site that is gone.

But there is a second point that almost nobody makes, and we ran into it on this very server.

The common WordPress migration plugin builds two hundred megabyte archives, puts them in a folder under wp-content, and protects that folder with a .htaccess file. On nginx that file does nothing at all; it is never even read. Before we wrote the rule that is there now, we tested it and found the archive downloadable over plain HTTP, with the server even honouring a partial download request. Inside each archive is the entire database: the user rows, the password hashes, the service keys and the contents of the configuration file.

Which means a perfectly good backup, sitting in the wrong place, becomes the largest leak available. One file, the whole site.

The way this site handles it now is to hand a request for such a file to PHP for an authorisation check; a logged in administrator gets the file and everybody else gets a 404. We tested it again today: a guest request for one of those archives, even with a partial request header, came back 404.

Three rules survive that story. A backup should not stay on the same machine, because a backup next to the site survives a mistake and does not survive the machine. Access to the backup should be as restricted as access to the database itself. And practise a restore once a year into a temporary folder; how to do that is covered separately in the computer basics track.

What is not worth your time

Now the position, plainly, because a large part of WordPress security advice consists of things that give a feeling of security without giving security.

Obscurity on its own is not a defence. Changing the address of the login page, hiding the WordPress version number and changing the table prefix close no vulnerability at all; they only slow an automated scanner down a little. Anyone who is targeting you specifically will find all three within minutes.

And now the honest half, because this site does all three of those things. The login address here has been changed and the plugin file paths have been rewritten as well. What that buys is less noise, not more security, and our own log shows both halves: in three days, 127 requests went to the default WordPress login address and not one of them reached a login form, because that address redirects a guest to another page. Those 127 requests were not removed; they simply no longer land on anything. If this same site were not kept updated, that changed address would not last a day.

Three more things that get recommended and that we do not recommend. Changing the database table prefix on a live site carries more risk than benefit; it half completes, and plugins that stored the prefix somewhere break. Turning the REST API off entirely breaks the WordPress editor and solves nothing that restricting access does not solve. And a security plugin whose contribution is a long list of firewall rules has added nothing if you never read the list.

There is a simple test you can put on any security recommendation: which specific attack does this stop, and what does it change if someone is already inside. Advice that has no clear answer to those two questions is usually a feeling.