The WordPress Security Hardening Checklist

Published 2026-03-29 · Last modified 2026-03-29

WordPress powers over 43% of the web, making it the single largest target for automated attacks. Every day, bots scan millions of WordPress installations looking for outdated plugins, weak credentials, and misconfigured permissions. The good news: most WordPress compromises are entirely preventable.

This checklist covers every layer of WordPress security, from the login page to the database, from file permissions to HTTP headers. Whether you manage one blog or a hundred client sites, work through each section systematically. Use our WordPress Security Scanner to verify your progress as you go.

Understanding the WordPress Attack Surface

Before hardening anything, you need to understand what attackers actually target. A typical WordPress installation exposes dozens of entry points, and each one requires specific defenses.

The Most Common Attack Vectors

WordPress compromises fall into a few well-documented categories, ranked by frequency:

Vulnerable plugins and themes – responsible for roughly 56% of all WordPress hacks. Plugins extend WordPress functionality but also extend its attack surface. A single SQL injection or file upload vulnerability in a plugin grants full access to the site.
Brute-force login attacks – automated tools like WPScan and Hydra attempt thousands of username/password combinations against wp-login.php and xmlrpc.php.
Core software vulnerabilities – less common since WordPress introduced auto-updates, but sites running ancient versions remain trivially exploitable.
Stolen credentials – credentials reused from breached databases or harvested through phishing are used to log in through the front door.
Server-level misconfigurations – world-readable wp-config.php, exposed .git directories, open directory listings, and missing security headers.

Read more about real-world plugin exploitation in our article on how attackers exploit outdated WordPress plugins.

Login and Authentication Security

The WordPress login page is the most attacked endpoint on any WordPress site. Hardening it is step one.

Enforce Strong Credentials

This sounds obvious, but weak passwords remain the number one cause of brute-force success. Enforce these rules:

Minimum 16-character passwords for all admin and editor accounts
Use a password manager – never reuse passwords across sites
Delete the default admin username and create a custom administrator account
Audit user accounts quarterly and remove unused accounts immediately

Enable Two-Factor Authentication (2FA)

2FA makes stolen credentials useless. Use TOTP-based 2FA (Google Authenticator, Authy) rather than SMS, which is vulnerable to SIM-swapping. Apply 2FA to every account with edit_posts capability or higher.

Limit Login Attempts and Hide wp-login.php

Rate-limit login attempts to block brute-force bots. After 5 failed attempts, lock the IP for 30 minutes. Consider moving wp-login.php to a custom URL, though this is security-through-obscurity and should complement, not replace, real protections.

Disable XML-RPC

The xmlrpc.php endpoint allows authentication bypass via the system.multicall method, enabling attackers to test hundreds of passwords in a single HTTP request. Unless you rely on the WordPress mobile app or Jetpack, disable it entirely:

# In .htaccess
<Files xmlrpc.php>
    Order Deny,Allow
    Deny from all
</Files>

Plugin and Theme Security

Plugins are the Achilles heel of WordPress security. Every plugin you install is third-party code running with the same privileges as WordPress core.

Minimize Your Plugin Count

Every active plugin increases your attack surface. Audit your plugin list ruthlessly:

Remove any plugin that is deactivated – deactivated plugins can still be exploited if they contain a directly accessible vulnerable file
Replace plugins with native WordPress functionality where possible
Check the last-updated date – plugins not updated in over 12 months are a red flag
Verify the plugin author's reputation and review the changelog for security patches

Use our WordPress Security Scanner to identify plugins with known CVEs. For JavaScript-heavy themes and plugins, run a JavaScript vulnerability scan to catch dangerous frontend libraries. Our article on scanning WordPress for known vulnerabilities walks through the full process.

Keep Everything Updated

Enable auto-updates for minor WordPress core releases (enabled by default since WordPress 5.6). For plugins and themes, enable auto-updates selectively or use a staging workflow:

# In wp-config.php – enable auto-updates for plugins
add_filter( 'auto_update_plugin', '__return_true' );

# Or selectively via the dashboard:
# Dashboard → Plugins → Enable auto-updates per plugin

File Permissions and wp-config.php

Incorrect file permissions are a silent vulnerability. On a compromised shared host, loose permissions let other accounts on the same server read your database credentials.

Recommended Permission Structure

# Directories: 755 (owner rwx, group rx, other rx)
find /var/www/html -type d -exec chmod 755 {} \;

# Files: 644 (owner rw, group r, other r)
find /var/www/html -type f -exec chmod 644 {} \;

# wp-config.php: 400 or 440 (owner read-only)
chmod 400 wp-config.php

# .htaccess: 444 (read-only for all)
chmod 444 .htaccess

Move wp-config.php Above the Web Root

WordPress automatically checks one directory above the web root for wp-config.php. Moving it there prevents direct HTTP access even if your server is misconfigured:

# If WordPress is in /var/www/html
mv /var/www/html/wp-config.php /var/www/wp-config.php

Disable File Editing in the Dashboard

The built-in theme and plugin editor lets any admin account modify PHP files directly from the browser. If an admin account is compromised, this is an instant backdoor. Disable it:

# In wp-config.php
define( 'DISALLOW_FILE_EDIT', true );

Database Security

The WordPress database contains everything: credentials, content, session tokens, and configuration.

Change the Default Table Prefix

The default wp_ prefix makes SQL injection attacks trivially scriptable. Change it during installation. For existing sites, changing the prefix is possible but requires updating the $table_prefix variable in wp-config.php and renaming every table and its references in usermeta and options.

Restrict Database User Privileges

The MySQL user for WordPress should have only the privileges it actually needs:

GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER
  ON wordpress_db.*
  TO 'wp_user'@'localhost';

Notably, FILE, PROCESS, SUPER, and GRANT OPTION should never be granted to the WordPress database user.

Add Salt Keys

WordPress uses secret keys and salts to secure cookies and session tokens. Generate fresh ones at https://api.wordpress.org/secret-key/1.1/salt/ and paste them into wp-config.php. Regenerate them if you suspect a compromise – this immediately invalidates all existing sessions.

.htaccess Hardening

The .htaccess file is your first line of defense on Apache servers. These rules block common attack patterns at the server level, before WordPress even loads.

# Protect wp-includes
<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteBase /
  RewriteRule ^wp-admin/includes/ - [F,L]
  RewriteRule !^wp-includes/ - [S=3]
  RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
  RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
  RewriteRule ^wp-includes/theme-compat/ - [F,L]
</IfModule>

# Prevent directory browsing
Options -Indexes

# Block access to sensitive files
<FilesMatch "(^\.ht|wp-config\.php|readme\.html|license\.txt)">
  Order Allow,Deny
  Deny from all
</FilesMatch>

# Disable server signature
ServerSignature Off

Also consider adding security headers through .htaccess or your server configuration. Headers like Content-Security-Policy, X-Frame-Options, and Strict-Transport-Security provide defense-in-depth against XSS, clickjacking, and protocol downgrade attacks. Test your headers with our Secure Headers Test tool.

Web Application Firewall (WAF)

A WAF inspects incoming HTTP requests and blocks malicious patterns before they reach WordPress. There are two categories:

Cloud-Based WAFs

Services like Cloudflare, Sucuri, and AWS WAF sit in front of your server as a reverse proxy. They filter traffic at the network edge, blocking attacks before they consume your server resources. Cloud WAFs also provide DDoS protection and CDN benefits.

Application-Level WAFs

Plugins like Wordfence and NinjaFirewall run as PHP code within WordPress. They offer WordPress-specific rulesets but consume server resources for every request. Read our comparison of WordPress security plugins versus manual hardening to understand the trade-offs.

WAF Rules to Prioritize

Block SQL injection patterns in query strings and POST bodies
Block file inclusion attempts (../, file://, php://)
Rate-limit wp-login.php and xmlrpc.php
Block known malicious user agents and IP ranges
Filter requests with abnormally long query strings (over 2048 characters)

Monitoring, Scanning, and Incident Response

Security is not a one-time configuration. You need continuous monitoring to detect compromises early.

File Integrity Monitoring

Compare your WordPress core files, plugin files, and theme files against known-good checksums. WordPress provides a built-in integrity check via wp core verify-checksums in WP-CLI. For plugins, use our WordPress Security Scanner to check for known vulnerabilities and unexpected file modifications.

Automated Vulnerability Scanning

Schedule regular scans of your WordPress installation. At minimum, scan for:

Plugins and themes with known CVEs – see our guide to scanning WordPress for known vulnerabilities
Outdated JavaScript dependencies in your theme – use the JavaScript Vulnerability Scanner
Missing or misconfigured security headers – use the Secure Headers Test
TLS configuration issues – verify with our SSL Certificate Checker and review our TLS best practices guide
Cross-domain policy risks from crossdomain.xml and clientaccesspolicy.xml – see our article on cross-domain policy risks

Uptime and Availability Monitoring

A sudden site outage or redirect to a malicious domain is often the first visible sign of compromise. Use a service like our Redirect Checker to verify your site loads correctly, and set up uptime alerts that notify you within minutes of downtime.

Incident Response Plan

When a compromise is detected, speed matters. Prepare a documented plan in advance:

Isolate – take the site offline or put it in maintenance mode immediately
Preserve evidence – copy access logs, error logs, and the compromised file system before making changes
Identify the vector – check access logs for the initial entry point (usually a vulnerable plugin endpoint)
Clean – restore from a known-good backup or manually remove all malicious files
Harden – patch the vulnerability that was exploited, rotate all credentials, regenerate salts
Monitor – watch closely for 30 days; re-compromises are common if the root cause was not fully addressed

HTTPS and Transport Security

Every WordPress site must run on HTTPS. In 2026, there is no excuse for serving any page over plain HTTP. Ensure TLS is configured correctly:

Force HTTPS for all pages, including wp-admin and wp-login.php: define( 'FORCE_SSL_ADMIN', true );
Set the Strict-Transport-Security header with a minimum max-age of 31536000 (one year)
Test your TLS configuration with our SSL Certificate Checker

Summary: The Complete Hardening Checklist

Use this condensed reference to verify every layer is addressed:

Strong unique passwords + 2FA on all admin accounts
Login rate limiting and XML-RPC disabled
All plugins, themes, and core updated; unused ones removed
File permissions locked down; wp-config.php moved above web root
Dashboard file editing disabled
Custom database table prefix; minimal MySQL privileges
Fresh security salts in wp-config.php
.htaccess hardened with directory protection and file blocks
Security headers configured (CSP, HSTS, X-Frame-Options)
WAF in place (cloud or application-level)
Automated vulnerability scanning on a schedule
File integrity monitoring active
HTTPS enforced with valid TLS certificate
Incident response plan documented and tested

Run each of these checks against your site now. Start with our WordPress Security Scanner for an instant overview, then work through this checklist item by item.