The WordPress Security Hardening Checklist for 2026

WordPress itself has a strong security record; the ecosystem around it is where sites get compromised. Almost every incident we have investigated traces back to an outdated plugin, a weak credential, or a hosting account with far more access than it needed. Hardening is not one magic plugin, it is a set of unglamorous decisions applied consistently. This is the checklist we work through on every site we take on, updated for how attacks actually look going into 2026.

Start with the boring fundamentals

Nothing on this list matters if updates do not happen. Core minor releases should auto-update, and plugins should be reviewed and updated on a schedule measured in days, not months, because vulnerability disclosures are weaponised within hours now. Run a supported PHP version, delete deactivated plugins and themes entirely rather than leaving them dormant, and be ruthless about plugin count: every plugin is code you have chosen to trust with your database.

Lock down authentication

• Enforce two-factor authentication for every administrator and editor account, without exceptions for founders or agencies.
• Use application passwords or scoped credentials for integrations instead of sharing a real admin login.
• Rate-limit login attempts and put wp-login.php behind your WAF rules or an allowlist where the team structure permits it.
• Audit accounts quarterly: remove leavers, downgrade roles that accumulated too much power, and check for administrators you do not recognise.

Credential stuffing remains the most common way into a well-patched site. Everything in this section is cheap to implement and blocks the majority of real-world attempts.

Reduce the attack surface

Anything the site does not need should be switched off. XML-RPC exists almost entirely for legacy clients and is a favourite amplification target; the file editor in wp-admin turns any compromised admin session into remote code execution; and the users endpoint of the REST API hands attackers a list of valid usernames. All three can go.

define( 'DISALLOW_FILE_EDIT', true );
define( 'FORCE_SSL_ADMIN', true );

add_filter( 'xmlrpc_enabled', '__return_false' );

add_filter( 'rest_endpoints', function ( $endpoints ) {
    if ( ! is_user_logged_in() ) {
        unset( $endpoints['/wp/v2/users'] );
    }
    return $endpoints;
} );

On sites where the team never installs plugins through the admin, DISALLOW_FILE_MODS goes further and disables installation and updates from the dashboard entirely, which pairs well with deployments managed in version control.

Harden the hosting layer

File permissions should stop the web server writing to code: wp-content/uploads is the only place WordPress genuinely needs write access on a locked-down site. Add security headers at the server, including Content-Security-Policy if you can invest the time to build one that fits your theme, and X-Frame-Options plus a strict referrer policy as the easy baseline. A web application firewall, whether at the CDN or on the host, buys you virtual patching time when the next plugin vulnerability drops before you have updated.

Isolation limits blast radius. Each site on a server should run as its own system user with its own database and credentials, so one compromised site cannot read its neighbours, and the database user WordPress connects with rarely needs more than the standard data privileges. Dropping the rest costs nothing day to day and blunts a whole class of injection attack.

Assume failure: monitor and rehearse

Hardening reduces probability; it never reaches zero. File integrity monitoring tells you when something changed that no deployment explains. An activity log tells you which account did what, which turns incident response from guesswork into a timeline. And off-site backups with a tested restore are the difference between a bad afternoon and a lost fortnight. If you have never actually restored one, you do not have backups, you have hope. Pair the logs with an external uptime check as well, because defacements and injected spam are too often reported by customers before anyone inside the organisation notices.

Work through this list once, then automate the checks so drift gets caught. Security is a posture you maintain, not a project you finish.

If you would like a second pair of eyes on your WordPress security posture, STRCLI runs hardening audits for exactly this purpose.