Security hardening is the process of reducing a WordPress site's attack surface before an attacker finds an opening. It is distinct from installing a security plugin. A plugin is one control. Hardening is a configuration state — the result of systematically closing the paths that attackers probe first.
These 15 controls are what security teams apply to business-critical WordPress sites. They are ranked by the size of the attack surface they close, not by how easy they are to implement.
Who this checklist is for
Site owners, developers, and security teams responsible for WordPress sites that handle revenue, leads, or customer data. These controls assume WordPress, PHP, and server-level access.
1. Enforce two-factor authentication on all admin accounts
Admin credential compromise is the most direct path into a WordPress site. Two-factor authentication (2FA) closes it. A strong password alone is not sufficient — password reuse across services means a breach elsewhere can expose your WordPress credentials. Use a dedicated 2FA plugin (WP 2FA, Google Authenticator for WP) and enforce it for all users with admin, editor, or author roles.
2. Change the default admin username
Automated attacks target the username admin because a large proportion of WordPress installs never change it. Use a non-guessable username. If you already have an admin account, create a new admin with a different username, transfer ownership, then delete the original account.
3. Limit login attempts
Without rate limiting, brute force attacks can make thousands of login attempts per minute. Plugins like Limit Login Attempts Reloaded or Loginizer cap failed attempts and block IPs after threshold breaches. At the hosting level, a WAF with rate limiting is more reliable than a plugin-based solution alone.
4. Disable XML-RPC if unused
XML-RPC was designed to allow remote publishing to WordPress. Most modern sites do not use it. Attackers use it for amplified brute force attacks (one XML-RPC request can test hundreds of passwords) and as a DDoS vector. Disable it entirely unless you have a specific integration that requires it.
Add to your .htaccess on Apache hosts:
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>5. Set correct file permissions
Overly permissive file permissions let attackers write malicious files to your server. The correct baseline:
- WordPress files: 644
- WordPress directories: 755
- wp-config.php: 600 (or 640 if your server requires group read)
- Uploads directory: 755 — no PHP execution allowed here
Block PHP execution in the uploads directory via .htaccess to prevent attackers from uploading and executing malicious scripts disguised as images.
6. Disable file editing in the WordPress admin
The built-in theme and plugin file editor lets anyone with admin access modify PHP files directly from the browser. An attacker who gains admin access can use it to inject code instantly. Add this to wp-config.php:
define('DISALLOW_FILE_EDIT', true);7. Keep wp-config.php out of the web root
WordPress automatically looks for wp-config.php one directory above the web root. Move it there. This means even if directory listing is accidentally enabled, the configuration file — which contains database credentials and security keys — is not publicly accessible.
8. Regenerate security keys and salts
Security keys and salts in wp-config.php protect user session cookies. If your site was previously compromised, regenerate them immediately — this invalidates all existing sessions, forcing every user to log in again. WordPress provides a generator. Do this after any confirmed breach and whenever you change admin credentials.
9. Restrict access to the wp-admin directory
If your admin team works from a predictable set of IP addresses, whitelist them at the server level. This does not need to be perfect (mobile IPs change) — even restricting to a broad CIDR block significantly reduces exposure. Combine with 2FA for defense in depth.
10. Run the minimum number of plugins
Every active plugin is a potential attack surface. Deactivate and delete plugins you are not actively using. Avoid plugins that are not maintained (no updates in over 12 months). Where two plugins do similar things, keep one. We typically see a 30–50% plugin reduction opportunity on sites that have grown by accumulation over several years.
11. Enable HTTPS and set security headers
HTTPS protects data in transit. Security headers protect the browser. The most impactful headers for WordPress sites:
- Strict-Transport-Security — forces HTTPS connections
- X-Content-Type-Options: nosniff — prevents MIME-type sniffing attacks
- X-Frame-Options: SAMEORIGIN — prevents clickjacking
- Referrer-Policy — controls referrer data sent to third parties
- Content-Security-Policy — restricts what scripts and resources can load
12. Configure a web application firewall
A WAF filters malicious requests before they reach WordPress. Cloud-based options (Cloudflare, Sucuri) operate at the DNS level and handle volumetric attacks. Plugin-based options (Wordfence) operate at the application level. For business-critical sites, a cloud WAF is preferred — it cannot be disabled by a PHP vulnerability. See our WordPress Firewall guide for a full comparison.
13. Set up automated, off-site backups
Backups are your recovery safety net, not a security control per se — but they are essential to hardening in the recovery sense. Requirements: automated (daily or more frequent for high-traffic sites), tested (restored at least quarterly), and off-site (not on the same server or hosting account). After a breach, you need a clean restore point that predates the infection.
14. Enable file integrity monitoring
File integrity monitoring (FIM) alerts you when WordPress files change unexpectedly. This catches attacker-planted backdoors and code injections that pass under the radar of signature-based malware scanners. Wordfence's real-time FIM, iThemes Security Pro, and server-level tools like OSSEC all provide this capability.
15. Audit and rotate credentials on a schedule
Hardening is not a one-time event. Credentials get reused, shared, and forgotten. Establish a process: audit admin user accounts quarterly, rotate database passwords and security keys annually or after any security event, review FTP/SSH access after any staff change.
Want these applied by a security specialist?
WebAdish applies this hardening framework as part of our security engagement and protection plans. We review your current configuration, close the highest-risk gaps first, and document what was applied and why.
Request a Security ReviewFrequently Asked Questions
Is security hardening a one-time task?
No. Hardening creates a baseline configuration, but maintaining it requires ongoing effort: credential rotation, plugin audits, reviewing new vulnerabilities as they are disclosed, and re-testing after major changes. Think of it as a configuration state that needs periodic revalidation.
Do security plugins handle hardening automatically?
Partially. Plugins like Wordfence, iThemes Security, and Solid Security automate some controls (file permissions, 2FA enforcement, login rate limiting) but cannot move wp-config.php, set server-level headers, or restrict directory access at the web server level. Plugin-based hardening should be combined with server-level configuration.
How long does WordPress hardening take?
For an experienced security engineer, a full baseline hardening engagement on a standard WordPress site takes 4–8 hours. Complex multisite installations, WooCommerce stores, or sites with large plugin stacks take longer because of the dependency mapping required before changes are applied.
Can hardening break my site?
Some controls can break specific functionality if applied without testing. Disabling XML-RPC breaks some mobile app integrations. Aggressive CSP headers can break third-party scripts. Restricting the admin by IP affects remote team members. Hardening should be staged and tested — ideally in a staging environment first.
Related resources
Continue with the pages buyers usually visit next after reading this topic.