Start with who is actually attacking you

Most WordPress sites are not targeted. They are swept. Bots crawl for known vulnerable plugin versions, probe /xmlrpc.php and /wp-login.php, and try credential stuffing against whatever usernames they can enumerate. The attacker does not know or care what your business does.

That shapes everything. You are optimising against automation, not against a human who will adapt. The cheap, boring, structural controls (patch currency, upload execution blocking, least privilege) buy you far more than clever obscurity. Hiding your WordPress version number buys you nothing: the scanner fingerprints your plugin assets anyway.

The exception: ecommerce and membership sites with real money moving through them do attract targeted attention, usually card skimming injected into checkout. If that’s you, the monitoring section matters more than the hardening section.

The WordPress security checklist we run before every handover

This is the actual list from our handover doc, trimmed of client-specific items.

1. PHP 8.2 or newer, and on a version still receiving security fixes. PHP 8.1 hit end of life in December 2025.
2. Core on the latest minor, auto-updates for minors enabled.
3. Full plugin and theme inventory, with last-updated date and active install count recorded.
4. Anything not updated in 12 months flagged for replacement.
5. PHP execution denied in wp-content/uploads and any other writable directory.
6. File editor disabled in wp-admin.
7. Administrator accounts counted and justified. Usually two.
8. 2FA mandatory on every account with edit_posts or above.
9. Default admin username absent, author enumeration closed.
10. XML-RPC off unless Jetpack or the mobile app is genuinely in use.
11. Backups running offsite, with a documented restore that someone has actually performed.
12. Vulnerability monitoring hooked to a channel a human reads.
13. Security headers set at the edge, HSTS included.
14. Staging environment that is not publicly indexable and does not share the production database.

Fourteen items. Most take minutes. The two that take real work are the plugin audit and the restore test, and those are the two most people skip.

The file and config layer costs nothing and stops the most

Start here. No ongoing maintenance, pure gain.

Block PHP in uploads. Apache, dropped into wp-content/uploads/.htaccess:

<FilesMatch "\.(?i:php|phtml|php[0-9]|phar|shtml)$">
  Require all denied
</FilesMatch>

Nginx, in the server block (note this must come before your generic PHP location or it will never match):

location ~ ^/wp-content/uploads/.\.(php|phtml|php[0-9]|phar)$ {
    deny all;
    access_log off;
}

Then the wp-config constants. Not all of them, and not blindly:

// No code editing from the dashboard, ever. Zero legitimate use on a maintained site.
define( 'DISALLOWFILEEDIT', true );

// Minor core updates install themselves. Majors stay manual.
define( 'WPAUTOUPDATE_CORE', 'minor' );

define( 'FORCESSLADMIN', true );

// If WP_DEBUG is ever left on in production, at least keep it out of the HTML.
define( 'WPDEBUGDISPLAY', false );
define( 'WPDEBUGLOG', '/var/log/wp/debug.log' ); // outside the webroot

DISALLOWFILEMODS is the one people recommend and then regret. It kills the plugin installer, the updater and the theme installer entirely. On a site where you deploy plugins through Composer and Git, set it. On a site where the client’s marketing lead needs to install a landing page plugin on a Friday, you have just created a support ticket that ends with someone commenting out the constant and never putting it back. Half-enforced hardening is worse than none, because you stop trusting your own config.

Permissions: directories 755, files 644, wp-config.php 640 or 600. The web user should not own the WordPress files it executes, with the exception of wp-content/uploads. If your host insists on 777 anywhere, change hosts.

Logins, sessions and the parts people get wrong

WordPress 6.8 switched default password hashing from the old phpass implementation to bcrypt. Genuinely meaningful. Also widely misunderstood: existing hashes are not rewritten on upgrade. They are rehashed the next time that user successfully logs in. An account that has not logged in since 2024 still has a weak hash sitting in your database.

Force a password reset after you upgrade a legacy site. Then put 2FA on everything with publishing rights.

Close enumeration while you are in there. A must-use plugin at wp-content/mu-plugins/hardening.php is the right home for this, because it cannot be deactivated from the dashboard:

<?php
/**

Plugin Name: Site Hardening
Description: Non-negotiable security defaults. Do not deactivate.
 */

addfilter( 'xmlrpcenabled', '__return_false' );

// Stop the X-Pingback header advertising an endpoint we have disabled.
addfilter( 'wpheaders', function ( $headers ) {
	unset( $headers['X-Pingback'] );
	return $headers;
} );

// The users endpoint hands out every author login. Require auth for it.
addfilter( 'restendpoints', function ( $endpoints ) {
	if ( isuserlogged_in() ) {
		return $endpoints;
	}
	unset( $endpoints['/wp/v2/users'] );
	unset( $endpoints['/wp/v2/users/(?P<id>[\d]+)'] );
	return $endpoints;
} );

// Never tell an attacker which half of the credential pair was wrong.
addfilter( 'loginerrors', function () {
	return 'Login failed.';
} );

One caveat on the users endpoint: if you have a decoupled front end reading authors over REST, this breaks it. Use an authenticated request with an Application Password instead of reopening the endpoint, and if you are building anything substantial on top of the API, the auth and caching patterns in our piece on custom REST API endpoints in WordPress will save you some rework.

Application Passwords deserve their own note. They are scoped to a user, not a capability, so an Application Password issued to a deploy script for an administrator account is an administrator credential. Create a dedicated user with the minimum role, issue the password to that user, and revoke it when the integration dies.

Plugins are the supply chain, and you are the one accepting the risk

If you only do one thing from this article, make it this. Core WordPress has a competent security team and a fast release cadence. The 60,000 plugins in the directory do not.

Our rules for taking a plugin to production:

• Last update inside six months. Not “tested up to” the current version, actual commits.
• Someone is reachable. A support forum with unanswered threads from 2024 is an abandoned plugin with a marketing page.
• Does it write to the filesystem or accept uploads? If yes, the bar goes up sharply. File upload handlers are where the critical CVEs cluster.
• Count the dependencies it drags in. A form plugin that bundles its own copy of a PDF library is three attack surfaces, not one.
• Could 30 lines in the theme replace it? Very often, yes.

Contact forms are the clearest example. A full form builder plugin gives you a database table of submissions, a file upload handler, an email sender and an admin UI, all to collect a name and a message. On static builds and on sites where we want the submission data out of WordPress entirely, we point the form at WebForms and delete the plugin. No PHP endpoint, no stored submissions to leak.

Run checksum verification as part of your routine. It catches modified core and directory-hosted plugin files, which is exactly the signature of the uploads-directory backdoor:

wp core verify-checksums
wp plugin verify-checksums --all

Inventory with pending updates, straight into your audit doc
wp plugin list --fields=name,version,updateversion,status,autoupdate

Who actually has admin?
wp user list --role=administrator --fields=userlogin,useremail,user_registered

For vulnerability alerting, Patchstack and Wordfence Intelligence both publish feeds. Pick one, wire it to Slack or email, and make sure the alert lands somewhere a human looks at within a day. An unread alert is not monitoring.

Push the blocking to the edge, not into PHP

Rate limiting login attempts inside WordPress means every attempt still boots the entire PHP stack, loads your plugins, hits the database, then declines. Under a credential stuffing run, that is how a “secure” site falls over from its own defences.

Do it upstream: Cloudflare rate limiting rules on /wp-login.php and /xmlrpc.php, fail2ban reading your access log, or your host’s WAF if it has one worth the name. Nginx can handle the simple case natively:

limitreqzone $binaryremoteaddr zone=wplogin:10m rate=20r/m;

location = /wp-login.php {
    limit_req zone=wplogin burst=5 nodelay;
    include fastcgi_params;
    fastcgi_pass php-fpm;
}

Headers belong at the edge too. HSTS, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin and a sane Permissions-Policy are all free.

Content Security Policy: a strict CSP on /wp-admin is not worth your time. The admin is full of inline scripts and third-party plugin assets, and you will spend a week on nonces and still break the block editor. Ship a real CSP on the front end, where you control the output, and leave the admin alone. If your front end is decoupled anyway, this gets dramatically easier, and the trade-offs there are covered in our take on headless WordPress.

Backups, and the restore nobody has tried

Three questions decide whether your backup strategy is real:

1. Can the WordPress server delete the backups? If the same credentials that run the site can reach the backup bucket, ransomware deletes both. Use write-only object storage credentials or a pull-based backup from outside.
2. How far back do you keep? Site compromises are frequently discovered weeks later. Seven days of retention means your only restore point is already infected. Keep 30 days minimum, with monthly snapshots beyond that.
3. When did someone last restore one? Not verified the file exists. Restored it, to a scratch host, and loaded the homepage.

We put the restore test on a calendar invite. It takes an hour and it is the only part of this list that has ever saved a client six figures.

When it has already happened

Order matters, and the instinct to start deleting malicious files first is wrong. Do this:

1. Rotate salts. wp config shuffle-salts logs out every session immediately, including the attacker’s.
2. Reset all passwords and revoke every Application Password.
3. Snapshot everything before you clean. Files and database. You will need it to work out the entry point.
4. Audit for persistence in the places people forget: wp-content/mu-plugins/, the drop-ins object-cache.php and advanced-cache.php, scheduled events (wp cron event list), unexpected administrator rows, and autoloaded wp_options entries with base64 in them.
5. Check the uploads tree for PHP: find wp-content/uploads -name '.php' -o -name '.phar'. There should be zero results.
6. Then restore from a clean backup and patch the entry point. Cleaning in place without identifying the vulnerability means you will be doing this again next month.