A WordPress security audit in 10 steps

Almost every WordPress site that gets compromised is compromised through something boring: an outdated plugin, a weak administrator password, or a forgotten account from a freelancer who left in 2023. A structured audit finds those before an attacker does.

Step one: inventory. Write down every plugin and theme, its version, and when it was last updated by its author. Anything not updated in the last twelve months is a candidate for removal, regardless of whether it currently has a known vulnerability.

Step two: known vulnerabilities. Compare that inventory against a vulnerability database. Sort by severity and by whether an exploit is publicly available. A medium-severity issue with a public exploit is more urgent than a high-severity theoretical one.

Step three: core and PHP versions. An unsupported PHP version means security fixes are no longer arriving at all, and the site may be missing months of patches without any warning in the admin.

Step four: accounts. List every user with administrator or editor rights. Remove people who no longer work on the site. For everyone who remains, require two-factor authentication and confirm that no account uses a shared password.

Step five: login surface. Check whether the login page has rate limiting, whether XML-RPC is needed at all, and whether the REST API exposes user enumeration. These three points account for most automated attack traffic.

Step six: file integrity. Compare the core files and plugin files against their official releases. Any modified file in wp-includes or wp-admin is a finding, not a curiosity. Automated scanning makes this a background task instead of a manual diff.

Step seven: file permissions and configuration. wp-config.php should not be world-readable, directory listing should be off, and file editing from the admin should be disabled on production.

Step eight: backups. Confirm backups exist, run automatically, are stored off-site, and can be restored. Then actually restore one to a staging environment. An untested backup fails exactly when you need it.

Step nine: transport and headers. Valid TLS, HTTPS enforced everywhere, HSTS enabled, and no mixed content. Add the basic security headers if the host does not set them for you.

Step ten: monitoring. An audit is a snapshot. Without uptime monitoring, malware scanning on a schedule, and alerts on new administrator accounts, everything you just verified is only true for today.

Write down every finding with a severity and an owner, and set a date for the re-check. An audit that produces a list nobody owns is a document, not a security measure.

If you maintain a portfolio rather than a single site, the hard part is repeating this ten-step pass consistently across every client every quarter. That is exactly the part worth automating: inventory, vulnerability matching, integrity scanning and monitoring can run on a schedule, leaving you with the findings instead of the fieldwork.