The First Three Security Plugins a Small WordPress Site Should Install

The site belonged to a physiotherapy clinic: nine pages, a booking form, and a slider on the homepage that nobody had looked at since the previous summer. It was defaced on a Tuesday, noticed on a Thursday, and cleaned by the host's emergency service on the Friday, which is how I ended up with it on a Saturday morning, a database dump in one window and the file listing in the other.

The way in was not interesting. The slider plugin had a publicly documented vulnerability that had been fixed upstream months earlier, and the fix sat in an update the clinic never ran, because the last person to touch the site had been paid once and had not come back. The administrator password was the clinic's name followed by the year they opened, and it was the same password as their booking system. Both facts are ordinary. Neither is unusual.

The third thing I found was the theme. It said it was premium. It had been downloaded from a forum thread offering it for testing, and the licence key field was empty. Somewhere in its includes directory was a file that pulled a remote script onto an admin screen nobody visited, and it had been sitting there for eleven months. That is what a nulled theme is: not a stolen design, but a directory of files of unknown provenance, running with the same privileges as everything else.

Disclosure: some links on this page are affiliate links, and WPSifero may earn a commission if you buy through them. That does not change the price you pay, and it does not change what this piece recommends: the first plugin below carries no affiliate link, and a section further down is about not buying the other two.

Three boring causes, and the eleven-plugin answer

Almost every small-site incident I have been called about reduces to one of three things, and all three are dull enough that nobody gives a conference talk about them.

• A plugin or theme that was not updated. The vulnerability was public, the fix existed, and the update sat unrun for months.
• An administrator password that was weak, reused, or both. Small sites usually have one account that matters, so one password stands between the internet and everything.
• Files from somewhere other than the official directories. A nulled theme, a cracked plugin, a pre-activated bundle from a downloads site. The code arrives with full privileges and no provenance.

None of those is a network event. That matters, because the category that sells hardest to small sites thinks in network events, which is how a site ends up with eleven security plugins and an update habit of zero.

What a firewall plugin does, and what it does not

A web application firewall sits in front of the request and decides whether to let it through. In WordPress the usual implementation is a plugin that inspects the request path, $_GET and $_POST early, before WordPress loads, and drops anything matching a rule. That is genuinely useful, and also the most oversold control in the category. So: which of the three causes above does it actually touch?

The unpatched plugin is partly covered. Rules describe known exploits against known vulnerable versions, so if the slider's flaw is in a rule set, the request is blocked before it reaches the code. If the flaw is two days old, or in a plugin the rule authors have never looked at, the request goes through and the vulnerability is exactly as exploitable as it was before the firewall existed. Free rule sets also publish new signatures on a delay measured in the same weeks an unpatched plugin is being actively scanned.

The password is barely touched. Rate limiting slows a brute force attempt, and that is worth something. It does not stop a correct guess, and it does not stop a credential list built from another breach being replayed against the login form, which is the attack most sites receive and which arrives as one request per address from a large pool. The control that answers it is a unique password and a second factor, neither of which a firewall provides.

The nulled theme is not touched at all. The backdoor is already inside the application, running in PHP with the same privileges as the rest of WordPress, on requests that look entirely normal because they are normal. A firewall inspects traffic crossing the perimeter; this code is already past it, and it does not need to knock.

So a firewall buys time against one of the three causes, and time is only worth having if somebody spends it on updates. Which is why the three worth installing are not three firewalls.

The first plugin: something that hardens the login

This comes first because it is the cheapest failure to prevent and the most common one. The job is narrow: require a second factor on every account that can publish or change settings, and enforce a password that is not in a public list.

The free option is genuinely enough, and it is what I install. Two Factor, maintained by core contributors, adds time-based one-time passwords and backup codes and does very little else, which is a virtue in a plugin sitting on the login path. Really Simple Security's free tier covers two-factor by email plus login attempt limiting, for a site where nobody will install an authenticator app. Several managed hosts also enforce two-factor at the account level, which is better than a plugin because it protects the login before WordPress is involved.

Two details decide whether this works. The second factor has to be enforced on the account that does the publishing, not offered as an option beside a "remind me later" link, and the recovery codes have to be stored somewhere other than the site. A second factor that can be switched off from the same password is a speed bump with a sign pointing around it.

What it is responsible for: the login. That is all. It will not notice a plugin with a known vulnerability, and it will not notice a modified file.

The second plugin: backups and file scanning

The second slot belongs to whatever answers two questions after a bad week: what did this site look like yesterday, and what changed that I did not change. Those are recovery controls, and they stop being optional once the site takes money or holds anything a customer would mind losing.

Jetpack's backup and malware scanning modules are the version of this I recommend most often, for one reason: they sit next to the site rather than inside it, so a compromise that disables plugins does not also disable the record of what happened. The free tier already includes login protection and downtime monitoring, which covers the "is it up, did somebody try the front door" half. Real-time backup and file scanning are on the paid plans, priced in tiers by what the site needs, so check the current price, they change it.

The free path is not embarrassing, and for a brochure site it is often correct. A host taking daily off-site backups, plus a free backup plugin pushing to remote storage, plus a vulnerability alert from the free Patchstack or WPScan tier, covers a good part of the same ground. What it does not cover is the file comparison. Knowing that wp-content/themes/ gained a file at 03:14 on a Sunday requires something that inventories the site and diffs it, and doing that by hand is a habit that lasts about three weeks.

What it is responsible for: the state of the site over time. It is the only one of the three that helps after a compromise rather than before one, which is why it takes a slot despite preventing nothing.

The third plugin: the comment form

Spam filtering gets filed under housekeeping, and the filing is wrong. The comment form is the one input on the site built to accept arbitrary text from strangers, write it into the database and email it to the owner, all without an account. Every automated tool that finds a WordPress site probes it there first, because it is the cheapest unauthenticated write path on the site and it is on by default.

What arrives is mostly noise, and that is the point. Spam is the visible fraction of a larger volume of automated submission: probes looking for an unprotected handler, tests for whether anyone triages, and link injection on the pieces nobody reads. Filtering it is not housekeeping. It is the only place where a stranger writes to your database, and the volume is a measure of how much attention that surface is getting.

Akismet hooks into the comment handler, sends the submission for classification, and blocks what it recognises before anything is stored. There is a free tier for personal, non-commercial sites and paid tiers for the rest, set by the size and nature of the site rather than by anything the reader controls; check the current terms, the tiers have moved before. Priced where it sits, it is small next to the hosting bill, and it is too much for a comment form that receives four comments a year.

That last line is the honest test. If comments are switched off, or allowed on a handful of posts, or require an account, the free option is to turn the form off and install nothing. A spam filter on a site with no comment volume is a plugin that exists to justify itself. One note against buying twice: the paid Jetpack plans already include anti-spam powered by the same filter, so a site on one of those does not need a second subscription, and a site on the free tier does.

What it is responsible for: the input surface strangers can reach. It is third not because it matters least but because the damage ceiling is lower. A spam flood is loud, annoying and recoverable. A stolen administrator account is not.

When the subscription is worth it, and when it is a dashboard nobody reads

The money wasted in this category is usually not the wrong plugin. It is the right plugin bought at the wrong tier, renewed for years, and never opened. A security dashboard is a control only if somebody looks at it in time to act, and the difference between a useful alert and an ignored one is nearly always whether one named person owns it.

Pay for the second slot when at least one of these is true. The site takes payments, or stores anything that would need to be disclosed if it leaked. Someone outside the business depends on the site being up, on a schedule, with a consequence attached. Nobody in the business can read a file listing, so recovery has to be a button rather than a procedure. Or the site has a history, because having been compromised once is the strongest predictor that it will be again.

Do not pay when the site is a brochure, the host already takes daily off-site backups, one person with a login runs updates within a week of release, and the worst realistic outcome is a day of downtime on a page that lists opening hours. In that situation the subscription buys a dashboard, a digest that gets filtered into a folder, and a renewal invoice. The money is better spent on the missing piece, which is the update habit.

The third slot answers to the same test and the same moderator.

The order, and what to do on Monday

Install the login control first, always, and enforce it on every account that can publish. That step is free and it removes the largest single category of small-site compromise. Then decide whether the site holds anything a day-old backup cannot fix, and buy the backup and scanning slot only if it does and nobody is going to run a manual file comparison. Then look at the comment form: if it is on and receiving anything at all, filter it; if it is off or irrelevant, leave it alone.

Notice what is missing from that sequence. Nothing in it fixes the slider plugin, and nothing in it vets the theme from the forum. Those are handled by a calendar reminder and by downloading from the official directory, and they are the reason the clinic's site was lost. The firewall would have bought a few weeks, which is only useful to somebody who was going to spend them updating. Install the three, then be the person who spends them.