Security on WordPress isn’t a checkbox. It’s a layered system that has to hold up against bots, opportunistic attackers, and the occasional targeted attempt — and the cost of getting it wrong has gone up. A compromised corporate site in 2026 means GDPR exposure, lost trust, weeks of forensic clean-up, and SEO damage that can take months to recover from.
This is the checklist I run through on every audit I take on. Not a generic “install Wordfence and call it a day” list — the layered controls that actually matter on mission-critical WordPress and WooCommerce sites.
1. Server and hosting layer
The strongest WordPress hardening doesn’t matter if the server underneath is shared with hundreds of other sites and the host doesn’t isolate them properly. Start here.
PHP version and isolation
Run a supported PHP version (8.2 or 8.3 as of 2026). Every release behind means missed security patches and worse performance. If your host is still serving PHP 7.4 in 2026, you’re paying for neglect.
For corporate sites, insist on isolated PHP-FPM pools per site, not a shared pool. This prevents one compromised neighbour from pivoting into your code or database connection.
Web Application Firewall
A WAF in front of WordPress filters the noise — XML-RPC abuse, brute-force attempts, common exploit signatures — before requests ever hit PHP. Cloudflare’s free WAF plus rate limiting handles 90% of the volume; for higher-risk sites, the Pro plan adds bot management and managed rules tuned for WordPress.
Plugin-based firewalls (Wordfence, Solid Security) sit inside PHP, which means they only act after PHP has already loaded. They have a place — application-layer rules, login monitoring — but they’re not a substitute for an edge WAF.
HTTPS and headers
TLS 1.2 minimum, ideally 1.3. HSTS header with at least a 1-year max-age once you’re confident the cert is stable. The other headers that should be in every response on a serious WordPress site:
X-Content-Type-Options: nosniffX-Frame-Options: SAMEORIGIN(or a proper CSPframe-ancestors)Referrer-Policy: strict-origin-when-cross-originPermissions-Policylocked down to the APIs the site actually usesContent-Security-Policy— the most painful to get right, but the highest impact
2. WordPress core
Core is the easy part — but it’s also where most “we got hacked” stories actually start. Almost always due to delayed updates or a misconfigured constant.
Auto-updates for minor and security releases
In wp-config.php, set define( 'WP_AUTO_UPDATE_CORE', 'minor' );. This applies security patches automatically without risking the breaking changes of a major version. Major version upgrades stay manual, staging-tested.
Disable file editing from the admin
This one line in wp-config.php blocks the most common post-compromise pivot — uploading malicious code through Appearance → Theme File Editor:
define( 'DISALLOW_FILE_EDIT', true );Pair it with DISALLOW_FILE_MODS if you don’t need plugin/theme installs through the admin — code changes go through Git anyway.
Salts and database prefix
Rotate the eight authentication keys and salts in wp-config.php at least once a year and immediately after any suspected compromise. Use the official WordPress.org generator. Custom database prefix (not wp_) is a small obstacle to automated SQL injection attempts — set it at install time; changing it on a live site is more risk than benefit.
3. Plugins and themes
This is where the actual attack surface lives. Every plugin is code running with full filesystem and database access. A neglected plugin from a vendor that disappeared two years ago is a ticking exploit.
Audit and prune
Once a quarter: list every installed plugin and ask three questions per plugin.
- Is this still being used? (Look at actual feature usage, not “it might be useful one day”.)
- Has it been updated in the last 12 months by the vendor?
- Does it have a published security disclosure policy?
If the answer to any of those is no, the plugin gets replaced or removed. Plugin sprawl is the single biggest predictor of a WordPress site getting compromised — more than core version, more than hosting.
Avoid nulled / pirated plugins
I shouldn’t have to say this in 2026 but I still find them on audits. Nulled premium plugins almost always come bundled with backdoors. The €99 you “save” on a year of WPML or a premium WooCommerce extension turns into a five-figure incident response invoice.
Lock down XML-RPC and REST API
XML-RPC is a legacy interface still enabled by default. Unless you’re using Jetpack or a remote publishing client, disable it entirely at the server level (a single nginx location block or .htaccess rule).
The REST API is more useful, but its default exposure of /wp-json/wp/v2/users leaks usernames to anonymous requests. Restrict that endpoint to authenticated requests with a small rest_authentication_errors filter.
4. Login and access
Most breaches start at the login form. Hardening it isn’t optional.
Two-factor authentication for every admin account
TOTP-based 2FA (via Wordfence Login Security, Two Factor, or a SSO provider) on every account with administrator or editor role. No exceptions, including yours. If you outsource development, your contractor gets their own account with 2FA, not a shared admin login.
Rename or rate-limit /wp-login.php
Security through obscurity is weak, but combined with rate limiting it does cut bot traffic significantly. Either move wp-login.php to a custom path (WPS Hide Login does this cleanly), or apply a strict rate limit at the WAF level — 5 attempts per 15 minutes per IP is reasonable.
Strong password policy enforced
WordPress’s built-in strength meter is suggestive, not enforcing. Use a plugin (Password Policy Manager, or built into your security suite) that blocks weak passwords. Minimum 12 characters, must include the four character classes, rejected against a known-leaked password list.
5. File system and permissions
A correctly-permissioned WordPress install limits the blast radius of any compromise.
- Directories:
755 - Files:
644 wp-config.php:600(readable only by the user the web server runs as)- Owner: the deploy user, not the web server user
- Web server user: read-only on everything outside
wp-content/uploads/and the few caches that need write access
Disable PHP execution inside wp-content/uploads/ at the server level. This is the single most useful defensive control against the “they uploaded a .php disguised as .jpg” attack pattern.
6. Database
The database is rarely the entry point but it’s almost always where the damage gets done — data exfiltration, admin user injection, malicious post content.
- Dedicated DB user per site with the minimum required privileges (no
GRANT, noDROP DATABASE) - DB and web server on private network; no public database port
- Encrypted backups stored off-server, retained for at least 30 days
- Restore tested at least twice a year — a backup you’ve never restored is a hope, not a backup
7. Monitoring and response
You will be compromised eventually. The difference between a 24-hour incident and a 6-week disaster is whether you find out from your monitoring or from a customer.
File integrity monitoring
A daily scan that compares the current filesystem against a known good baseline. Any modified core file, any new PHP file in wp-content/uploads/, any change to .htaccess generates an alert. Wordfence does this; so do enterprise tools like OSSEC.
Uptime and behaviour monitoring
Simple uptime checks (UptimeRobot, BetterUptime) catch the obvious. More useful: response time anomaly detection — a site that suddenly slows by 3× often has a cryptominer in wp-content/uploads/.
Documented response plan
Written before you need it: who calls who, what gets taken offline, where the latest clean backup lives, what the GDPR notification flow looks like if personal data was exposed. A 1-page document beats a perfectly-architected plan you’ll never read in panic.
What this looks like in practice
The full checklist is 30+ controls. Most sites I audit have 5 to 10 of them in place — the cheap ones, plus whatever the original developer remembered. The remaining 20 are where the real risk reduction is.
The good news: you don’t need a six-month security project to get to a defensible state. The first half of this list — server hardening, core constants, plugin audit, 2FA, file permissions — gets done in two or three focused days. The rest is a quarterly rhythm.
If you’d rather not be the one running through all this, that’s exactly what the WordPress Engineering Audit covers — the same security review delivered as a prioritised remediation plan.
