WordPress security: the realistic checklist

WordPress security is unglamorous, and the unglamorous parts are what work. Sites get compromised by automated bots scanning for outdated plugins, reused passwords and abandoned software, so the moves that matter, roughly in order, are: keep everything updated, keep backups you have restored, run least-privilege user accounts, limit login attempts, put a WAF or CDN in front of the origin, and disable file editing from the admin. Nobody is choosing your site by name. An hour spent on clever hardening before those six items is an hour spent in the wrong place.

The threat model, stated plainly

A new WordPress site starts receiving automated probes almost as soon as its domain resolves. The probes are not personal and not clever: scripts sweep address ranges, fingerprint WordPress, check plugin versions against public vulnerability lists, and run password dictionaries against the login form. The economics favor volume, so the bar is low. A site on current software with strong credentials costs more to break than the next site, and the scanner moves on. The realistic goal is that one, because being harder than the neighbour is the whole strategy.

Updates carry most of the weight

Known-vulnerable plugin versions are the front door, and bots rattle the handle automatically. The monthly update habit closes it, and nothing else on this list compensates for a site running last year's version of a popular form plugin. The cadence, the staging pass for major updates and the plugin audit that retires abandoned code, is described in our monthly WordPress maintenance checklist.

Backups you have restored

Security work lowers the odds of a bad week; backups cap the cost of one. A hacked site with a clean, tested restore point is an afternoon of cleanup. Without one it is a rebuild, because attacker code in plugin files and the database leaves no trustworthy starting place. The bar is specific: a backup whose restore you have personally watched succeed. A green icon in a panel is a schedule, and a schedule is a claim.

Accounts with least privilege

One administrator account, used for administrating. Everyone else gets the role their work requires, editors editing and authors authoring, and every human gets their own login, because a shared password cannot be revoked when somebody who knew it leaves. Passwords come from a password manager, long and unique, and two-factor authentication goes on every admin account. When a plugin or integration needs API access, hand it an application password scoped to that purpose, and keep the main account's credentials out of third-party settings screens.

Limiting login exposure

The login form is the one door bots can knock on forever. Limit login attempts so a password dictionary cannot run to completion, and let repeat failures be blocked at the server or hosting layer, where the requests die before PHP wakes up. Two-factor on top makes a guessed password insufficient on its own. Apply some care to your own lockout rules: the classic self-inflicted outage is a security plugin that locked the owner out of the site on a Friday evening.

A WAF or CDN in front

A web application firewall sits in front of the origin and drops the obvious garbage before it reaches your server: scans for known plugin exploits, injection patterns, brute force. A CDN adds traffic absorption on top of the same filtering. The common setup is Cloudflare in front of the site, and it changes the bot experience from your server answering every probe to most probes dying at the edge. The setup walkthrough lives in putting Cloudflare in front of WordPress.

Two lines in wp-config.php

DISALLOW_FILE_EDIT is one constant that removes the theme and plugin code editors from the admin. That closes an accident vector, the quick fix that takes the site down, and an attacker convenience, malware pasted into a theme file through the admin. While the file is open, paste in fresh salts when inheriting a site or cleaning up after an incident: rotating the keys invalidates every signed cookie, which ends sessions you cannot enumerate.

The inversion: plugins cause the risk

Every plugin is PHP running with the site's full privileges, so each one adds attack surface, and security plugins are no exception. An all-in-one suite with its own firewall, scanner, login guard and dashboard is among the most privileged software on the site, needs its own update discipline, and has shipped vulnerabilities like any other plugin. The security tool protecting you is itself a thing to secure. A password manager, one or two small purpose-built plugins where a gap exists, hosting-level blocking and a CDN do most suites' work with a fraction of the surface.

What the hardening marketing sells that you do not need

Stacked plugins doing overlapping jobs, arguing with each other's rules and slowing every page. Renaming the admin path or hiding the version string, which adds one step for a scanner and nothing against anything else. Disabling XML-RPC wholesale without checking what relies on it, which breaks integrations you forgot about. Malware scan subscriptions on sites with no tested restore path, detecting problems you cannot recover from. The common thread is that each product sells certainty, while the real protection still comes from updates, restorable backups, disciplined accounts, login limits, an edge filter, and a locked-down admin editor.