WordPress Hardening Checklist: HSTS Preload, OWASP ASVS & NIST CSF

Performance note: Images are compressed to ≤200 KB where feasible; WebP/AVIF preferred and lazy-loaded to minimize layout shifts.

Why hardening WordPress matters in 2024–2025

Attackers continue to target widely deployed web stacks. Verizon’s DBIR analyzed 22,052 incidents and 12,195 breaches—its highest breach count to date (2025), underscoring persistent web-app and credential-driven attacks (Verizon DBIR 2025).

Meanwhile, average breach costs remain painful: IBM reported a global average of USD 4.88M in 2024, up from 2023 (IBM 2024), with 2025 research highlighting governance gaps around AI usage (IBM 2025). For EU operators, NIS2 and sectoral rules like DORA raise the bar on risk management, incident reporting, and supply-chain control (ENISA/EU sources: ENISA on NIS2; DORA regulation).

Bottom line: pairing basic hygiene with a defensible, auditable checklist mapped to OWASP and NIST CSF reduces likelihood and blast radius—and speeds compliance evidence gathering.

The WordPress Hardening Checklist (38 steps)

Source frameworks: WordPress Hardening Guide; OWASP ASVS categories (authentication, session, access control, validation, configuration); NIST CSF (Identify-Protect-Detect-Respond-Recover).

Quick wins (≈30–60 minutes)

1. Enforce TLS 1.3 end-to-end (origin ↔ CDN/WAF ↔ visitor). Add Strict-Transport-Security and consider HSTS preload after confirming HTTPS everywhere (IETF TLS 1.3 via Wikipedia summary with RFC refs, TLS 1.3).
2. Update core, themes, plugins (remove unused). WordPress explicitly recommends pruning code you don’t need (WordPress Hardening).
3. Disable file editing in the dashboard: add define('DISALLOW_FILE_EDIT', true); to wp-config.php (WordPress).
4. Force HTTPS for wp-admin and logins (define('FORCE_SSL_ADMIN', true);).
5. Two-factor authentication (2FA) for all admins; require app passwords for API/write clients (OWASP auth guidance, OWASP).
6. Rate-limit / lockout login attempts (WAF, Fail2ban at reverse proxy, or a minimal plugin).
7. Backups: enable automatic off-site daily database + weekly full file backups (3-2-1-1-0), and test restore.
8. Principle of Least Privilege: convert shared “Admin” accounts into named users with minimal roles (NIST CSF Protect; NIST CSF).
9. XML-RPC: disable unless needed for Jetpack/mobile publishing; otherwise 403 or remove_action hooks.
10. Directory listing: disable via server config (Options -Indexes in Apache or autoindex off; in Nginx).

Security headers & transport

• HSTS: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload (verify readiness before preloading).
• CSP (Content-Security-Policy): start with Content-Security-Policy-Report-Only to collect violations, then enforce. This mitigates XSS and content injection (CISA website security tips mention CSP, CISA 2021).
• X-Content-Type-Options: nosniff; X-Frame-Options: SAMEORIGIN (or frame-ancestors CSP).
• Referrer-Policy: strict-origin-when-cross-origin.
• Permissions-Policy: restrict powerful APIs (camera, geolocation, etc.).
• OCSP stapling and modern ciphers on the origin; prefer ECDHE & AEAD suites.

Accounts, least privilege & auth

• Roles & capabilities: give Author/Editor only what’s needed; avoid Admin for routine publishing (OWASP ASVS).
• 2FA everywhere: TOTP preferred; keep recovery codes offline.
• Password policy: length ≥14, breach-checked (HaveIBeenPwned API in your IdP/WAF if available).
• SSO/IdP integration for teams; disable legacy/basic auth on the edge.
• Application passwords: scope-limited, rotate quarterly, remove stale.

Files, configuration & patching

• File permissions (Linux): wp-config.php 600, files 640, directories 750; owner = web user or deploy user, group = web group.
• Move wp-config.php one level above docroot when supported.
• Set WP_DEBUG false in production; route PHP errors to logs, not the page.
• Disable XML-RPC (repeat) or throttle specific methods like system.multicall.
• Disallow wp-content/uploads PHP execution via .htaccess or Nginx location rules.
• Auto-updates: enable security auto-updates; stage major upgrades in a staging site first.
• Signatures/malware scanning: run a scheduled scan (server level or plugin) and monitor integrity.
• Audit logging: capture logins, role changes, plugin/theme installs, file edits.

WAF/CDN & bot mitigation

Use a fronting WAF/CDN for virtual patching, bot scoring, and rate limiting. OWASP highlights injection and broken access control risks that WAFs can help detect/mitigate when tuned (OWASP 2021).

• Blocklists/allowlists: gate /wp-login.php and /xmlrpc.php by IP/CIDR or country when justified.
• Geo & ASN policy: reduce noise from regions you never serve.
• Bot management: challenge high-risk non-human traffic; don’t punish accessibility tools or search bots.
• mTLS for admin behind VPN when feasible.

Backups, RTO/RPO & DR

• 3-2-1-1-0: 3 copies, 2 media, 1 offsite, 1 immutable/air-gapped, 0 errors (verified)—then document RTO/RPO.
• Run restores quarterly in a sandbox; time the process and update SOPs.
• Config backups for Nginx/Apache/PHP-FPM and WAF rules in source control.

Security headers & TLS: examples

# Nginx (snippet)
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "geolocation=(), camera=()" always;

# Apache (snippet)
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "geolocation=(), camera=()"

Which hosting/WAF makes this easier?

Choose providers that simplify TLS 1.3, HSTS, backups, staging, and WAF policy. Below is a high-level comparison oriented to WordPress hardening features.

For TLS certificates beyond Let’s Encrypt (e.g., OV/EV, mTLS pilots), use a dedicated CA marketplace: SSLs.com or Namecheap.

Risk vs. effort matrix

FAQs

Is WordPress inherently insecure?

No. The platform ships with sane defaults, but security depends on configuration and timely patching. WordPress itself documents common pitfalls and fixes (WordPress Hardening).

Which threats are most common for small sites?

Credential attacks, plugin/theme vulnerabilities, and misconfigurations remain prevalent. DBIR 2025 again highlights credentials/social as frequent breach paths (DBIR 2025).

Do I need HSTS preload?

Preloading is powerful but sticky. Only submit when every subdomain enforces HTTPS and you control DNS/cert issuance (IETF TLS 1.3 context via TLS 1.3).

What about EU compliance (NIS2/DORA)?

Many WordPress operators won’t be directly in scope, but NIS2’s risk management expectations influence suppliers; DORA is binding for EU financial entities from Jan 17, 2025 (ENISA NIS2; DORA).

Should I disable XML-RPC?

Yes, unless a concrete workflow needs it. If required (e.g., Jetpack), throttle and monitor.

Do I need a WAF?

A tuned WAF helps with virtual patching, brute-force throttling, and bot management (aligned to OWASP risks, OWASP).

How often should I test restores?

Quarterly at minimum; time them and compare to your RTO/RPO targets (IBM’s reports show recovery is a major component of breach costs, IBM 2024).

Mini glossary (quick, plain English)

• ASVS: OWASP Application Security Verification Standard (control catalog for web apps).
• CSP: Response header telling browsers what sources of scripts/styles are allowed.
• CSF: NIST Cybersecurity Framework (Identify/Protect/Detect/Respond/Recover).
• HSTS: Header that forces HTTPS and blocks HTTP downgrade/stripping.
• RPO/RTO: Data loss tolerance / time to restore service targets.
• WAF: Web Application Firewall that filters/monitors HTTP traffic.
• WP-CLI: Command-line tool for managing WordPress.
• XML-RPC: Legacy API endpoint used by some services; frequent brute-force target.
• SRI: Subresource Integrity—hash to ensure scripts/styles weren’t altered.
• OCSP stapling: TLS performance and revocation check optimization.
• Fail2ban: Tool that bans IPs with repeated failed auth at the server layer.
• 3-2-1-1-0: Backup rule ensuring multiple copies, one immutable, and zero errors after verification.

Practical mapping: OWASP ASVS & NIST CSF

Image & Video Credits

• “Full TLS 1.3 Handshake” — Source: Wikimedia Commons · Author: Fleshgrinder · License: CC0 · Dimensions used: 1280×877 PNG preview (~<200 KB).
• “Server Racks on Data Center” — Source: Pexels · Author: Brett Sayles · License: Free commercial use · Dimensions served: 1200×800 (~<200 KB).
• Inline SVG “Security headers flow” — Source: Author-made (SentinelEra), no external rights required. Dimensions: 1200×528.