WordPress Security Hardening: A Practical Checklist

WordPress's popularity is exactly why it's attacked constantly — not usually by a human targeting your site specifically, but by bots scanning millions of sites for known plugin vulnerabilities, weak credentials, and default configurations. Almost every successful compromise traces back to one of a small set of preventable gaps. Here's how to close them, roughly in order of impact.

1. Keep everything updated — and know what "everything" means

The single biggest source of WordPress compromises is an outdated plugin or theme with a disclosed vulnerability. Once a CVE is public, automated scanners start probing for it within hours.

• Core, plugins, and themes all need to stay current. Enable auto-updates for minor core releases at minimum; consider auto-updates for plugins on sites you can't check daily.
• Remove what you don't use. A deactivated-but-installed plugin is still a vulnerability if its files are on disk and reachable — delete it, don't just deactivate it.
• Audit plugin quality before installing. Check last-updated date, active install count, and the changelog for security fixes. A plugin untouched for two years is a liability regardless of what it does.

2. Harden authentication

Brute-force and credential-stuffing attacks against wp-login.php are constant background noise on the open web.

• Enforce strong, unique passwords for every account with publish or admin capability — a password manager, not a policy nobody follows.
• Add two-factor authentication. This alone stops the overwhelming majority of account-takeover attempts, since credential-stuffing bots don't have your second factor.
• Rate-limit or block login attempts after repeated failures, ideally at the server/firewall level rather than in PHP — a plugin doing this still costs a full WordPress bootstrap per attempt.
• Rename or restrict wp-login.php and xmlrpc.php where practical. XML-RPC in particular is a common amplification vector for brute-force and DDoS pingback abuse; disable it entirely if you don't use the mobile app or remote publishing.
• Never reuse the default admin username. It's the first thing every brute-force script tries.

3. Lock down file permissions and editing

If an attacker does get a foothold, the next question is how much damage they can do.

• Disable file editing from wp-admin: add define('DISALLOW_FILE_EDIT', true); to wp-config.php. This closes the built-in theme/plugin editor, a favorite tool for planting a backdoor once an attacker has admin access.
• Set correct file permissions — typically 644 for files, 755 for directories, and wp-config.php tightened further (600 or 440 where the server user allows it).
• Disable PHP execution in wp-content/uploads. Uploaded media should never be executable — this single rule neutralizes a huge class of "upload a PHP shell as an image" attacks.

4. Protect wp-config.php and secrets

• Move wp-config.php above the web root if your hosting setup supports it, so it's never directly reachable over HTTP.
• Rotate the authentication salts and keys (AUTH_KEY, SECURE_AUTH_KEY, etc.) periodically and immediately after any suspected compromise — this invalidates all existing sessions and cookies.
• Never commit wp-config.php or .env-style secrets to version control.

5. Put a firewall in front of the application

A Web Application Firewall (WAF) — ideally at the server or network edge, not just a PHP-level plugin — filters known attack patterns (SQL injection, XSS payloads, malicious file upload attempts) before they ever reach WordPress. This matters because plugin-level firewalls still let the malicious request execute PHP before blocking it; an edge WAF stops it cold.

Pair this with virtual patching for disclosed plugin vulnerabilities — many managed hosts and security plugins can block exploit attempts against a known CVE even before you've had a chance to update.

6. Back up like you expect to need it

Hardening reduces risk; it doesn't eliminate it. The difference between a security incident and a disaster is whether you have a clean, recent, offsite backup.

• Automate daily backups of both files and database, stored somewhere other than the same server.
• Test restores periodically. A backup you've never restored from is a backup you don't actually have.
• Keep enough history (7–30 days) to restore from before a compromise was introduced, not just the most recent snapshot — which may already be infected.

7. Monitor and respond

• Enable file integrity monitoring to catch unexpected changes to core files — a classic sign of a planted backdoor.
• Watch for new admin users, unfamiliar scheduled tasks (cron), and unrecognized files in wp-content.
• Have a response plan: rotate credentials, restore from a known-clean backup, update everything, and only then bring the site back online. Cleaning an infected site file-by-file without a clean restore point is a losing game — reinfection is common.

The takeaway

WordPress security hardening isn't one silver bullet — it's closing the handful of doors that automated attacks actually try: outdated software, weak credentials, executable uploads, exposed config, and no clean backup to fall back on. Get those seven areas right and you've eliminated the vast majority of real-world attack paths against a WordPress site.