After 15 years of hardening WordPress sites for healthcare providers, law firms, financial services companies, and e-commerce brands, we’ve distilled our internal security process into this 52-point audit checklist. Use it before launch, after a security incident, or as part of a quarterly security review.
This checklist covers every layer of a WordPress site: core configuration, login security, user permissions, file system, database, SSL, server rules, plugins, and monitoring. We use this exact checklist on every client site we touch at Zao.
How to Use This Checklist
Work through each section in order. Check off items as you complete them. Items marked with ⚠️ are high-priority — these are the vectors most commonly exploited in WordPress compromises we’ve remediated over 15 years.
Tools referenced throughout: Wordfence, iThemes Security Pro, Sucuri, WP-CLI, and Cloudflare WAF.
Section 1: Core WordPress Configuration (8 Points)
- ☐ 1. WordPress core is updated to the latest stable release
- ☐ 2. ⚠️
wp-config.phpfile permissions set to 400 or 440 - ☐ 3.
wp-config.phpmoved one directory level above the webroot (if your host supports it) - ☐ 4. Debug mode disabled in production (
define('WP_DEBUG', false);) - ☐ 5. ⚠️ File editing via WordPress admin disabled (
define('DISALLOW_FILE_EDIT', true);) - ☐ 6. ⚠️ Unique authentication keys and salts configured in
wp-config.php(regenerate using the WordPress Salt Generator) - ☐ 7. WordPress version number removed from
<head>and RSS feeds - ☐ 8. Automatic updates enabled for minor and security releases
Section 2: Admin & Login Security (8 Points)
- ☐ 9. ⚠️ Default “admin” username removed or changed — this is the first username brute-force attacks try
- ☐ 10. ⚠️ Admin login URL changed from
/wp-admin/using WPS Hide Login or iThemes Security - ☐ 11. ⚠️ Two-Factor Authentication (2FA) enabled for all accounts with admin or editor roles
- ☐ 12. Strong password policy enforced — minimum 16 characters, mixed case, numbers, symbols
- ☐ 13. ⚠️ Login attempt rate limiting active (Wordfence Brute Force Protection or Limit Login Attempts Reloaded)
- ☐ 14. CAPTCHA on login page (reCAPTCHA v3 or Cloudflare Turnstile) to block automated credential stuffing
- ☐ 15. ⚠️
xmlrpc.phpdisabled or restricted to specific IPs — XML-RPC is a common DDoS and brute-force amplifier - ☐ 16. WordPress REST API user enumeration endpoint restricted (prevents exposing usernames via
/wp-json/wp/v2/users)
Section 3: User & Role Management (6 Points)
- ☐ 17. All user accounts audited — every admin-level account has a named, active, known owner
- ☐ 18. User roles follow least privilege — editors don’t have admin access, subscribers don’t have editor access
- ☐ 19. Inactive user accounts (former employees, past contractors) removed or deactivated immediately
- ☐ 20. Open user registration disabled if this is not a membership or community site
- ☐ 21. Application passwords audited — revoke any that are unused or unrecognized
- ☐ 22. Author archive pages reviewed — WordPress exposes usernames in author URLs by default (
?author=1redirect)
Section 4: File & Directory Permissions (7 Points)
Misconfigured file permissions are among the most common vulnerabilities we find in WordPress audits. Verify these via SSH, SFTP, or WP-CLI. These settings apply to Linux-based servers.
- ☐ 23. WordPress root directory permissions:
755 - ☐ 24.
/wp-admin/directory permissions:755 - ☐ 25.
/wp-includes/directory permissions:755 - ☐ 26.
/wp-content/directory permissions:755 - ☐ 27. All PHP files permissions:
644 - ☐ 28. ⚠️
wp-config.phppermissions:400or440(never world-readable) - ☐ 29.
.htaccessfile permissions:444(read-only to prevent modification)
Section 5: Database Security (5 Points)
- ☐ 30. ⚠️ Database table prefix changed from the default
wp_— makes automated SQL injection significantly harder - ☐ 31. Database user has minimum required privileges only (SELECT, INSERT, UPDATE, DELETE — not GRANT, DROP, or FILE)
- ☐ 32. Database server bound to
127.0.0.1or a private network — not exposed to the public internet - ☐ 33. ⚠️ Automated daily database backups scheduled and verified restorable (UpdraftPlus, WP-CLI cron, or managed hosting)
- ☐ 34. Database backups stored offsite (S3, Google Drive, Dropbox) and encrypted at rest
Section 6: SSL & Data Transmission Security (4 Points)
- ☐ 35. ⚠️ SSL certificate installed, valid, and set to auto-renew before expiration
- ☐ 36. HTTPS enforced site-wide with no mixed content warnings (verify in browser console or with a mixed content checker)
- ☐ 37. HTTP Strict Transport Security (HSTS) header configured:
Strict-Transport-Security: max-age=31536000; includeSubDomains - ☐ 38.
SecureandHttpOnlyflags set on WordPress auth cookies to prevent cookie theft over HTTP
Section 7: .htaccess & Server Hardening (6 Points)
- ☐ 39. ⚠️
wp-config.phpaccess blocked via.htaccess:<files wp-config.php> deny from all </files> - ☐ 40. Directory browsing disabled:
Options -Indexesin root.htaccess - ☐ 41. ⚠️ PHP execution blocked in
/wp-content/uploads/— prevents attackers from uploading and executing malicious PHP files - ☐ 42. Sensitive disclosure files blocked publicly:
readme.html,license.txt,wp-config.php.bak,.env - ☐ 43. XML-RPC access blocked via
.htaccessdeny rules if your site doesn’t use it (Jetpack and some plugins require it) - ☐ 44. Cloudflare WAF or server-level firewall configured with rules to block known malicious IPs and attack patterns
Section 8: Plugin & Theme Security (6 Points)
- ☐ 45. ⚠️ All plugins updated to their latest versions — outdated plugins are the single most common WordPress attack vector
- ☐ 46. All themes updated to their latest versions, including inactive themes
- ☐ 47. ⚠️ Unused plugins completely deleted (not just deactivated) — deactivated plugins still contain exploitable code on the filesystem
- ☐ 48. Unused themes completely deleted — keep only your active theme and one default WordPress theme as fallback
- ☐ 49. ⚠️ All plugins and themes obtained from the official WordPress.org repository or verified commercial sources — zero nulled or pirated software
- ☐ 50. Active commercial plugin and theme licenses verified — expired licenses mean no security updates
Section 9: Monitoring & Incident Response (2 Points)
- ☐ 51. ⚠️ Automated security scanning active and scheduled — Wordfence (free or premium), Sucuri SiteCheck, or iThemes Security run daily scans and alert on malware, file changes, and vulnerabilities
- ☐ 52. ⚠️ Activity and audit logging enabled — WP Activity Log or Wordfence activity log records logins, failed login attempts, file changes, plugin activations, and user role changes
Why We Created This Checklist
Over 15 years of building and maintaining WordPress sites for healthcare organizations, legal firms, financial services companies, and e-commerce brands, our team at Zao has responded to dozens of compromised sites. The pattern is almost always the same: one or two of these 52 items were skipped.
This checklist covers everything we check on every client engagement — from the quick wins (updating plugins, changing the admin URL) to the deeper server-level hardening (file permissions, .htaccess rules, Cloudflare WAF configuration). We use WP-CLI to automate many of these checks across multiple client sites simultaneously.
For regulated industries — HIPAA-covered healthcare entities, legal firms handling client data, financial services under PCI-DSS — several of these items aren’t optional. They’re compliance requirements. If you’re in a regulated industry and need a documented security audit trail, our team can provide that.
Related Resources
- WordPress Development Services — Custom development built with security baked in from day one
- Zao Blog — Tutorials, security tips, and WordPress development insights from our team
- Our Work — See secure, high-performance WordPress sites we’ve built for clients in regulated industries
Need Something More Custom?
Our team has hardened WordPress sites for healthcare, legal, and financial services organizations for 15+ years. Get a professional security audit or a custom hardening engagement.