WordPress security — a production hardening reference

For: anyone running a WordPress site. No attack steps here — this is a working reference for hardening: a priority-ordered checklist, per-area guidance, and self-verification. For the cross-framework picture, see the security-by-framework hub.

Priority-ordered hardening checklist

Do this table top-down. P0 is top priority, P1 is the most frequent source of incidents, P2 is ongoing operational hygiene.

1. Updates (the top defense)

Most attacks on WordPress are automated tools hitting a published known vulnerability (CVE) at scale. So update speed is your biggest defense.

• Enable automatic updates for core, plugins, and themes — close published holes before they're hit.
• For important sites, verify major updates in staging and back up before updating.
• A skipped update is an open entry for automated attacks. Don't "do it later."

2. Plugins and themes (attack surface)

Third-party code vulnerabilities are the biggest entry. The key is to keep the count low and never leave them unattended.

• For anything unused, delete rather than deactivate (deactivated files can still be a target).
• Before installing, check update frequency, adoption, last-updated date, and known CVEs. Avoid abandoned ones.
• You can check plugin CVEs with the CVE/KEV lookup. Fewer extensions means less update responsibility and less attack surface.

3. Admin accounts and authentication

Most takeovers are brute-force against weak/reused admin accounts, or reuse of leaked passwords.

For choosing 2FA see what 2FA is; for the route that targets admins see what phishing is.

4. Reduce exposure (admin surface and disclosure)

Attackers first look for a "usable entry." Cut unused features and unnecessary disclosure.

• Add login-attempt limits to reduce the effectiveness of brute force.
• Restrict xmlrpc.php if unused (it can be an entry for brute-force amplification and high-volume requests).
• Suppress REST-API user enumeration (prevent exposing admin names via ?author= etc.).
• Disable directory listing and reduce unnecessary version disclosure.
• Disable file editing from the admin (DISALLOW_FILE_EDIT) to make post-intrusion tampering harder.

5. wp-config and secrets (P2)

• Set the unique authentication keys/salts and protect wp-config.php with appropriate permissions (never world-readable).
• Keep secrets like DB credentials off the public surface. Don't leave backups or exports in a public directory (→ keep secrets out of public directories).
• In production, disable debug display (WP_DEBUG_DISPLAY off). Don't leak internals via errors.

6. Files and uploads (P2)

• File permissions of roughly 644 files / 755 dirs, and stricter for wp-config.php. Never leave anything world-writable.
• Don't allow PHP execution in the uploads directory (web-shell defense). Validate upload type and size.
• Use tamper detection (file-change monitoring) to spot post-intrusion changes early.

7. HTTPS, headers, backups (P2)

• Force HTTPS + HSTS. Resolve mixed content.
• Add security headers (check your own site with the security headers checker).
• Keep offline/immutable backups + restore tests so you can recover (→ backup essentials). The last line against ransomware and defacement.

8. Hosting and dependencies (P1–P2)

• Keep PHP and the database on supported versions. Don't leave EOL versions in place.
• Know your hosting's patch status (on shared hosting, that includes the provider's response).
• A WAF is a supplement — firm up the foundation (updates, minimization, auth, backups) first.

Verify: is your WordPress actually hardened?

Building it isn't the end — it's done only once you've checked. These are defensive self-checks against your own site.

Read next

• Hub: security by framework · Laravel security
• Practice: the vulnerability-response playbook · backup essentials
• Secrets/auth: keep secrets out of public directories · what 2FA is · what phishing is
• Tools: security headers checker · CVE/KEV lookup