WordPress Security Checklist: 2026 Practitioner Guide

A WordPress security checklist is the diagnostic that catches what attackers will exploit before they get the chance. Every WordPress site has known security weaknesses — outdated plugins with public CVEs, default admin usernames, weak credentials, no WAF, files writeable by web server user. The checklist surfaces them; the fixes prevent the inevitable compromise.

This guide is the practitioner-grade WordPress security checklist I run on every audit in 2026. It covers server hardening, plugin + theme audits, user account security, WAF setup, file permissions, database security, and the monitoring patterns that catch new issues as they emerge. Concrete checks with concrete fixes.

Quick verdict: the eight highest-leverage WordPress security wins are (1) keep core/themes/plugins updated, (2) enforce 2FA for admin roles, (3) WAF at edge (Cloudflare), (4) strong unique passwords, (5) limit login attempts, (6) audit user accounts quarterly, (7) backup + tested disaster recovery, (8) ongoing malware scanning. Skip any one and you have a real attack surface.

The 10 areas every WordPress security audit covers

High-level scope of a thorough audit:

• Server + PHP configuration
• WordPress core hardening (wp-config.php, .htaccess)
• Theme + plugin vulnerability scan
• User accounts + roles + 2FA
• Login protection (brute force, IP blocking)
• File permissions + ownership
• Database security (table prefix, credentials)
• Backups + disaster recovery
• WAF + DDoS protection
• Monitoring + alerting

Server + PHP configuration

Server-level defaults that should be on every WordPress site:

• HTTPS everywhere — Let’s Encrypt or commercial SSL, HSTS header set
• PHP version current — 8.2+ in 2026; 8.1 is end-of-life
• disable_functions in php.ini — disable exec, system, shell_exec, passthru
• open_basedir restriction — limit PHP to specific directories
• session.cookie_httponly + secure — prevent JS access to session cookies
• Server software hidden — remove “Server” header revealing Apache/Nginx version
• X-Frame-Options + Content-Security-Policy headers

WordPress core hardening

wp-config.php hardening checklist:

• WP_DEBUG = false in production
• DISALLOW_FILE_EDIT = true to prevent admin theme/plugin editor
• WP_AUTO_UPDATE_CORE = 'minor' for security auto-updates
• Salts — fresh salts via api.wordpress.org/secret-key/1.1/salt
• Database table prefix — change from default wp_ to random prefix
• wp-config.php permissions — 600 (owner read/write only)
• FORCE_SSL_ADMIN = true

wp-config.php is the highest-value target: wp-config.php contains database credentials, salts, and security keys. If it is readable by the web server, a path traversal vulnerability exposes everything. File permissions of 600 + storing it ABOVE the web root (when host allows) is the gold standard. At minimum, 644 with web server unable to execute it.

Theme + plugin vulnerability scan

Most WordPress compromises trace back to outdated plugins. The audit:

• WPScan API check — every active plugin against CVE database
• Inactive plugins removed — code on server even when inactive
• Theme code review — for custom themes, check for known vulnerable patterns
• Abandoned plugins identified — plugins not updated in 12+ months
• Update schedule — security updates within 7 days of release

User accounts + roles + 2FA

User account security:

• Default admin username changed — never use “admin”
• Inactive admin accounts removed — old contractors, ex-employees
• 2FA enforced for admin + editor roles — WP 2FA, Two Factor Authentication plugin
• Password requirements — minimum 12 characters, complexity rules
• Role audit — every user has the minimum role needed
• User enumeration prevention — block ?author=N queries

Login protection

Login is the most-attacked endpoint:

• Brute force protection — limit login attempts per IP per hour
• WP login URL changed — WPS Hide Login plugin moves /wp-admin/ to custom URL
• CAPTCHA on login — for sites with sustained attack traffic
• IP allowlist for admin — when team is in known IP ranges
• Disable XML-RPC — prevent XML-RPC brute force amplification
• Login attempt logging — alerting on suspicious patterns

File permissions + ownership

Correct file permissions reduce attack surface:

• Directories — 755
• Files — 644
• wp-config.php — 600 (most restrictive)
• .htaccess — 644
• Owner — usually web server user (www-data or apache)
• Group — usually web server group
• NOT 777 — never give world-writable permissions

Database security

Database hardening:

• Custom table prefix — random prefix instead of default wp_
• Database user limited privileges — only what WordPress needs (SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, DROP, INDEX)
• Database credentials in wp-config.php only — not committed to git
• Regular database backups — automated, offsite, tested
• SQL injection mitigation — handled by WordPress core for proper code; verify custom plugins use prepared statements

Backups + disaster recovery

A backup that has never been tested is not a backup:

• Daily automated backups — UpdraftPlus, BackupBuddy, host-included
• Offsite storage — S3, Google Cloud Storage, Backblaze B2 — NOT same server as production
• Retention policy — daily for 7 days, weekly for 4 weeks, monthly for 6 months
• Test restore quarterly — verify backup files actually restore to a working site
• Documented disaster recovery plan — who, what, where, when

WAF + DDoS protection

Edge protection layers:

• Cloudflare — free tier covers basic WAF + DDoS; Pro $20/mo for advanced rules
• Wordfence — WordPress-specific WAF at the application layer
• Layered defense — Cloudflare at edge + Wordfence at origin = catches more attacks
• Rate limiting — protect login + API endpoints from abuse
• Bot mitigation — Cloudflare Bot Fight Mode or similar

Monitoring + alerting

Ongoing security monitoring catches new issues:

• File integrity monitoring — Wordfence, MalCare, or custom WP-CLI scripts
• Login attempt logging — alerting on suspicious patterns
• Plugin/theme update monitoring — alert when new versions available
• Uptime monitoring — UptimeRobot, Better Uptime, alert on outages
• SSL certificate expiry — alert before expiry
• Malware scans on schedule — Wordfence Premium daily scans

Audit basics — FAQs

How often should I run a WordPress security audit?

Annual deep audit for most sites. Twice yearly for high-revenue sites or compliance obligations (PCI, HIPAA, GDPR-sensitive). After any major change (theme switch, plugin overhaul, host migration). Always after suspected compromise. Between deep audits, ongoing monitoring (Wordfence, MalCare, file integrity) catches new issues.

Can I do a WordPress security audit myself?

For basic checks (update plugins, change default passwords, enable 2FA, activate a security plugin), yes. For comprehensive audits (file integrity verification, WPScan API checks, custom plugin code review, server hardening, database security), professional audit catches what DIY misses. Layer both: DIY ongoing maintenance + annual professional audit.

What is the most common WordPress security mistake?

Outdated plugins. WordPress core is reliably updated; themes are usually fine. Plugins are where 60-80% of WordPress compromises start. Specifically: abandoned plugins (not updated in 12+ months) and security plugins themselves (when administrators delay their own updates). Audit plugin update history quarterly.

Defense layers — FAQs

Do I need both Cloudflare WAF and Wordfence?

For high-target sites (ecommerce, membership, high-revenue), yes — layered defense catches more. Cloudflare blocks at edge before traffic hits your server; Wordfence blocks at WordPress level after traffic arrives. Different attack vectors, different defenses. For low-target sites, either alone is acceptable. Cloudflare free + Wordfence free is solid for most.

Should I disable XML-RPC on WordPress?

For most sites: yes. XML-RPC is rarely used in modern WordPress (Jetpack and remote publishing apps use REST API now). XML-RPC is frequently abused for brute force amplification — single request tries hundreds of credentials. Disable via Disable XML-RPC plugin or .htaccess rule. For sites that genuinely need XML-RPC (older Jetpack flows), restrict by IP.

How do I know if my WordPress site is hacked?

Symptoms: unexpected admin users, unfamiliar files in /wp-content/, Google “deceptive site” warning, slow performance, spam content auto-published, blacklisting by Sucuri / Google Safe Browsing, modified core files. Diagnosis tools: Wordfence scan, Sucuri SiteCheck, MalCare. If suspected, take site offline temporarily and run thorough scan + clean rebuild.