The WordPress security baseline we apply to every site

Most WordPress compromises we clean up are not clever. They are an abandoned plugin with a known vulnerability, a reused administrator password, or a backup that turned out to be empty on the day it was needed. After years of running care plans across hundreds of sites, we stopped treating security as a bespoke exercise per client and wrote down a baseline: twelve controls that every site gets before we accept it into maintenance. None of them are exotic. Applied together, they account for almost all of the attacks we see bounce off rather than land.

Why a baseline beats a checklist of plugins

The instinct on a new WordPress site is to install a security plugin and consider the job done. Plugins help, but they run inside the same PHP process an attacker is trying to subvert, and many of them bundle a dozen features that overlap with the host, the CDN and each other. A baseline is different: it describes outcomes, and each outcome can be met at whichever layer is most reliable for that site. Sometimes that is a plugin, more often it is server configuration, a managed firewall or a process your team follows.

It also makes audits fast. When a site drifts, we can tell in minutes which control failed rather than untangling a pile of settings screens.

The twelve controls

Access and identity

1. Two-factor authentication for every account that can publish. Not just administrators. Editors can upload files and inject scripts through custom HTML blocks, so they are in scope.
2. Least-privilege roles. We typically find three to five administrator accounts on a site that needs one or two. Everyone else is downgraded to editor or author, and agency or freelancer accounts are removed when a project ends.
3. Login rate limiting at the edge. Credential stuffing against wp-login.php and xmlrpc.php is constant. We throttle both at the firewall or web server, and disable XML-RPC entirely unless a known integration needs it.

Code and updates

4. A written update policy. Minor core releases and security patches apply within 24 hours; plugin updates go to staging first and reach production within seven days. Anything waiting longer needs a documented reason.
5. A plugin budget. Every plugin must have a named owner, an active maintainer and a reason to exist. Sites that arrive with 40 plugins usually leave with 15 to 20.
6. No file editing from the dashboard. We set DISALLOW_FILE_EDIT and, on sites deployed from Git, DISALLOW_FILE_MODS so code only changes through the deployment pipeline.
7. Correct file permissions and no PHP execution in uploads. The uploads directory should never run code. A two-line server rule closes one of the most common persistence tricks.

Infrastructure

8. A web application firewall in front of the origin. Managed rulesets catch the bulk of automated exploit attempts before PHP ever boots. We run managed rules in log mode for a few days, then switch to blocking.
9. TLS everywhere, with HSTS. Mixed-content warnings and plain-HTTP admin sessions are still more common than they should be.
10. Isolated environments. One site per system user or container. Shared hosting accounts running ten client sites under one user are how a single infection becomes ten.

Recovery and visibility

11. Off-site, versioned backups with a tested restore. Daily database and file backups, kept for at least 30 days, stored outside the hosting account, and restored to staging at least once a quarter.
12. File integrity and uptime monitoring. We compare core and plugin files against known checksums daily and alert on unexpected changes, along with uptime and certificate expiry checks.

A control you cannot verify in five minutes is a control you will eventually stop maintaining. Every item on the baseline has a quick, repeatable check.

How we roll it out on an existing site

Onboarding a live site is where the baseline earns its keep, because you rarely inherit a clean install. Our sequence is roughly the same every time:

• Snapshot first. Take a full backup before touching anything, and store it somewhere the current host cannot reach.
• Scan and compare. Run a malware scan and verify core files against official checksums. If anything looks wrong, we stop and treat it as an incident rather than hardening on top of a compromise.
• Inventory users and plugins. Export the user list, flag anyone who has not logged in for 90 days, and list every plugin with its last update date and active install count.
• Apply controls in low-risk order. Backups and monitoring go live on day one. Firewall rules and login throttling follow in monitoring mode before switching to block. Role changes and plugin removal are scheduled with the client, because they affect people.
• Document exceptions. A membership site might genuinely need XML-RPC for a mobile app. That is fine, as long as it is written down and compensated for elsewhere.

On a typical marketing site this takes one to two days of engineering time. Complex WooCommerce or multisite installs take longer, mostly because plugin removal needs careful regression testing.

What the baseline does not cover

Twelve controls will not make a site immune. They are designed to defeat opportunistic, automated attacks, which are the overwhelming majority of what reaches small and mid-sized WordPress sites. They do less against a targeted attacker, a compromised developer laptop or a malicious insider. For those risks we add threat modeling, code review of custom plugins and, where the stakes justify it, independent testing. Our security audits start from the baseline and then look for the specific ways a given business could be hurt.

The baseline also depends on people. Two-factor authentication fails when staff share one account to save a seat. Update policies fail when nobody reads the staging report. We keep the process small on purpose so that it survives turnover on both sides.

Measuring whether it works

Across the sites in our care plans, the pattern is consistent. Sites that meet all twelve controls rarely need a malware cleanup; when they do, the cause is usually an exception someone forgot to revisit. Sites missing two or more controls account for most of our incident hours. We track three numbers monthly: the share of sites fully on baseline, median days from plugin security release to production patch, and the date of the last successful restore test. If any of those slip, we know before an attacker does.

If you want the baseline applied and maintained for you, it is included in every one of our monthly care plans, and it is also the starting point of our WordPress security hardening engagements.

Get your site on the baseline

Send us the URL and a rough plugin count, and we will come back within a day with a fixed price to audit and harden it. Request a fixed-price quote and we will tell you exactly which of the twelve controls you already have.