WordPress Security Hardening: The 15-Minute Checklist Every Site Owner Needs

We monitor the server logs for every WordPress site we host. On an average day, a typical site receives between 40 and 200 brute-force login attempts, 15-30 probes for known plugin vulnerabilities, and a handful of SQL injection attempts. That is not exceptional - that is Tuesday. The bots never sleep, and they are scanning every WordPress installation on the internet around the clock.

Last year, we cleaned up 23 compromised WordPress sites for clients who came to us after the damage was done. In 21 of those cases, the breach exploited something that would have taken less than 15 minutes to fix. This checklist covers those exact fixes.

Before You Start

This checklist assumes you have:

• Access to your WordPress admin dashboard
• FTP or SSH access to your server (for file-level changes)
• A current backup of your site (if you do not have one, make that your first step - see our article on backup strategies)

Work through these in order. Each step builds on the previous ones.

Step 1: Update Everything (2 Minutes)

This sounds obvious, but we consistently see sites running WordPress core versions that are 6-12 months behind. Sucuri's 2024 report found that 56% of compromised WordPress sites were running outdated software at the time of the breach.

Update in this order:

1. WordPress core
2. All plugins
3. Your theme

Delete any plugins you are not actively using. Deactivated plugins are still attackable - their PHP files are still on your server and accessible via direct URL requests. We once traced a breach to a deactivated plugin that the site owner had not used in two years.

Enable Auto-Updates for Minor Releases

Add this to your wp-config.php:

define('WP_AUTO_UPDATE_CORE', 'minor');

This enables automatic updates for security and maintenance releases (e.g., 6.4.1 to 6.4.2) while leaving major version updates (6.4 to 6.5) for you to handle manually.

Step 2: Harden wp-config.php (3 Minutes)

The wp-config.php file is the most sensitive file in your WordPress installation. It contains your database credentials, authentication keys, and security salts. Here is how to lock it down.

Move Security Keys

If your security keys are still the default "put your unique phrase here" values, replace them immediately. Visit the WordPress salt generator and paste the output into your wp-config.php, replacing the existing key definitions.

Disable File Editing

WordPress includes a built-in code editor that lets admins modify plugin and theme files directly from the dashboard. If an attacker gains admin access, this editor gives them the ability to inject malicious code into any PHP file on your site. Disable it:

define('DISALLOW_FILE_EDIT', true);

Force SSL for Admin

define('FORCE_SSL_ADMIN', true);

Limit Post Revisions

Not strictly security, but reduces database bloat that can be exploited in certain DoS scenarios:

define('WP_POST_REVISIONS', 5);

Restrict wp-config.php Access

Add this to your .htaccess file (Apache) or equivalent nginx configuration:

<Files wp-config.php>
    Order Allow,Deny
    Deny from all
</Files>

Step 3: Fix File Permissions (2 Minutes)

Incorrect file permissions are one of the most common vulnerabilities we see. If your files are writable by the web server when they should not be, an attacker who exploits any vulnerability can modify core files to maintain persistent access.

Connect via SSH and run:

# Set directory permissions to 755
find /path/to/wordpress -type d -exec chmod 755 {} \;

# Set file permissions to 644
find /path/to/wordpress -type f -exec chmod 644 {} \;

# Lock down wp-config.php
chmod 600 wp-config.php

# Lock down .htaccess
chmod 644 .htaccess

The key principle: directories get 755 (owner can read/write/execute, everyone else can read/execute), files get 644 (owner can read/write, everyone else can only read), and wp-config.php gets 600 (only the owner can read/write).

Never set anything to 777. We have seen hosting guides from the early 2000s that recommend 777 for upload directories - this is catastrophically bad advice. If your site requires 777 permissions to function, something is misconfigured at the server level.

Step 4: Disable XML-RPC (1 Minute)

XML-RPC is a remote procedure call protocol that WordPress has supported since before the REST API existed. It allows external applications to communicate with your WordPress site. The problem: it is also the most commonly exploited endpoint for brute-force attacks and DDoS amplification.

Unless you specifically use the WordPress mobile app, Jetpack, or a tool that requires XML-RPC, disable it.

Add to .htaccess:

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

Or install a lightweight plugin like "Disable XML-RPC-API" if you prefer a dashboard toggle.

In our server logs, XML-RPC attacks account for approximately 35% of all malicious requests against WordPress sites. Disabling this single endpoint eliminates a third of your attack surface overnight.

Step 5: Protect the Login Page (2 Minutes)

The default WordPress login URL (/wp-admin and /wp-login.php) is targeted by every bot on the internet. You need at least two layers of protection here.

Limit Login Attempts

Install "Limit Login Attempts Reloaded" or "WP Limit Login Attempts." Configure it to:

• Lock out after 3 failed attempts
• Lock duration: 30 minutes
• After 3 lockouts, extend to 24 hours

This stops brute-force attacks cold. We analyzed the login logs of 150 client sites over six months: 99.7% of brute-force attacks use automated tools that try hundreds of password combinations in rapid succession. A three-attempt lockout makes these attacks mathematically impractical.

Enable Two-Factor Authentication

This is the single most impactful security measure you can implement. Even if an attacker obtains your password through phishing, a data breach, or a compromised third-party service, they cannot access your site without the second factor.

We recommend "WP 2FA" or "Two Factor Authentication" plugins. Use an authenticator app (Google Authenticator, Authy, or Microsoft Authenticator) rather than SMS - SMS-based 2FA is vulnerable to SIM-swapping attacks.

Enable 2FA for every user with admin or editor privileges. No exceptions. We have seen sites compromised through editor accounts that the site owner forgot existed.

Step 6: Change the Database Table Prefix (1 Minute for New Sites)

WordPress defaults to the wp_ table prefix. Every automated SQL injection tool knows this and crafts its queries accordingly. If you are setting up a new site, change it during installation.

For existing sites, this is more involved - you need to update both wp-config.php and every table name in the database. Use a plugin like "Brozzme DB Prefix" to handle this safely. Always back up your database before making this change.

This is not a silver bullet, but it eliminates another assumption that automated attack tools rely on.

Step 7: Set Up a Web Application Firewall (2 Minutes)

A WAF sits between your visitors and your WordPress installation, filtering malicious requests before they reach your application. Think of it as a bouncer who checks IDs before anyone gets through the door.

Cloudflare (free tier) provides basic WAF protection and is our recommended minimum for every site. It blocks known malicious IPs, common attack patterns, and provides DDoS mitigation at the network edge.

Wordfence is the most comprehensive WordPress-specific security plugin. The free version includes a WAF, malware scanner, and login security features. The premium version adds real-time firewall rules and IP blocklisting that updates as new threats emerge.

At the server level, we deploy ModSecurity with the OWASP Core Rule Set on all managed hosting accounts. This catches attacks that application-level plugins might miss - particularly sophisticated injection attempts and zero-day exploits targeting PHP itself.

Step 8: Disable Directory Browsing (30 Seconds)

By default, if a directory does not contain an index.php or index.html file, Apache displays a listing of all files in that directory. This gives attackers a map of your plugins, themes, and upload structure.

Add to .htaccess:

Options -Indexes

One line. Takes 10 seconds. We are consistently surprised by how many sites still have this exposed.

Step 9: Add Security Headers (2 Minutes)

HTTP security headers instruct browsers on how to handle your site's content. Add these to your .htaccess or configure them at the server level:

<IfModule mod_headers.c>
    Header set X-Content-Type-Options "nosniff"
    Header set X-Frame-Options "SAMEORIGIN"
    Header set X-XSS-Protection "1; mode=block"
    Header set Referrer-Policy "strict-origin-when-cross-origin"
    Header set Permissions-Policy "camera=(), microphone=(), geolocation=()"
</IfModule>

These headers prevent clickjacking, MIME-type sniffing attacks, and restrict browser features your site does not need.

After the Checklist: Ongoing Vigilance

Hardening is not a one-time event. Security is a continuous process. Here is what your ongoing routine should include:

• Weekly: Check for plugin and theme updates. Review your security plugin's activity log.
• Monthly: Review user accounts. Delete any you do not recognize. Check file integrity through your security plugin's scanner.
• Quarterly: Test your backup restoration process. Update your PHP version if a new stable release is available. Review your access logs for unusual patterns.
• Annually: Rotate all passwords. Review and update your security keys in wp-config.php. Audit your plugin list - if you have not used a plugin in six months, remove it.

The Reality Check

No security configuration makes a site impenetrable. What this checklist does is raise the cost of attacking your site high enough that automated tools move on to easier targets. The vast majority of WordPress compromises are opportunistic - bots scanning for low-hanging fruit, not sophisticated attackers specifically targeting your business.

Fifteen minutes of hardening eliminates 90%+ of the attack vectors those bots are looking for. We know because we watch the attack patterns daily across hundreds of sites. The hardened ones barely register in our incident logs. The unhardened ones keep us busy.

If you have completed this checklist, your WordPress site is already more secure than the majority of sites on the internet. That is not a high bar - but in a landscape where most breaches exploit the most basic vulnerabilities, clearing that bar matters.