WordPress Security Hardening: Advanced Protection Beyond the Basics

Author: Edric Martinez, Lead Developer & WP Troubleshooter
Reading time: 12 minutes
Last updated: April 2025

—

Why Basic Security Isn’t Enough

You’ve installed Wordfence, set a strong password, and keep everything updated. That’s table stakes — the minimum any WordPress site needs. But if you’re handling client sites, e-commerce stores, or any site with sensitive data, you need to go deeper.

Advanced WordPress security hardening protects against the attacks that slip past standard plugin defenses: file injection through compromised FTP credentials, privilege escalation through plugin vulnerabilities, and database tampering through SQL injection. These aren’t theoretical — I see them weekly.

This guide covers the security measures most sites skip, but every serious WordPress installation should implement.

—

The WordPress Attack Surface

Understanding what attackers target helps you defend it:

Attack Vector	Common Method	Impact
wp-login.php	Brute force / credential stuffing	Site takeover
XML-RPC	Amplified DDoS / brute force	Performance collapse
Plugin vulnerabilities	Exploiting known CVEs	Remote code execution
File uploads	Malicious PHP in disguised files	Backdoor installation
Database	SQL injection	Data theft / corruption
wp-config.php	File exposure	Full database access
Theme editor	Admin compromise	File modification

—

Step 1: Lock Down wp-login.php

The WordPress login page is attacked constantly. Bots hammer it 24/7.

Change the Login URL

Don’t use /wp-login.php or /wp-admin. Change it with a plugin or server config.

Plugin method (WPS Hide Login):

Install WPS Hide Login
Go to Settings → WPS Hide Login
Set a custom login URL (e.g., /your-secret-login)
Set redirect URL for unauthorized access attempts

Nginx method:

nginx
location ~ ^/(wp-login\.php|wp-admin) {
    allow 192.168.1.0/24;  # Your IP
    deny all;
}

Implement Rate Limiting

Block IPs after failed login attempts:

Using Wordfence:

Brute Force Protection → Enabled
Lock out after 3 failed attempts
Lockout duration: 4 hours

Using Cloudflare (if behind CDN):

Security → Bots → Configure Super Bot Fight Mode
Enable “Definitely automated” blocking

Using server-level blocking (fail2ban):
Install fail2ban and configure a WordPress jail:

ini
[wordpress]
enabled = true
filter = wordpress
logpath = /var/log/apache2/access.log
maxretry = 3
bantime = 3600

Disable XML-RPC

Unless you use the WordPress mobile app or Jetpack, disable XML-RPC:

Plugin method:
Install Disable XML-RPC. One toggle, done.

.htaccess method:

apache

    Require all denied

Nginx method:

nginx
location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
}

—

Step 2: Harden File Permissions

Wrong file permissions make it easy for attackers to modify files.

Correct Permission Structure

File/Directory	Permission	Owner	Group
WordPress files	644	www-data	www-data
WordPress directories	755	www-data	www-data
wp-config.php	600 or 640	www-data	www-data
.htaccess	644	www-data	www-data
uploads directory	755	www-data	www-data

Never use 777. If a tutorial says to chmod 777, find a better tutorial.

Secure wp-config.php

Move wp-config.php one directory above web root if possible. Many hosts allow:

/home/username/wp-config.php        ← Move here
/home/username/public_html/        ← Web root

If your host doesn’t allow this, restrict access via .htaccess:

apache

    order allow,deny
    deny from all

Nginx equivalent:

nginx
location = /wp-config.php {
    deny all;
}

Disable File Editing

Prevent theme/plugin editing from the admin panel:

Add to wp-config.php:

php
define('DISALLOW_FILE_EDIT', true);

This removes the “Theme Editor” and “Plugin Editor” from the admin menu. Even if an attacker gets admin access, they can’t modify files through the UI.

—

Step 3: Database Security

Change Database Table Prefix

The default wp_ prefix makes SQL injection attacks easier. Change it during installation, or use a plugin for existing sites.

For new sites: During wp-config.php setup, set:

php
$table_prefix = 'x7k9m_';

For existing sites: Use the Change DB Prefix plugin. Backup first — this modifies every table name.

Restrict Database User Privileges

Create a database user with minimal privileges:

sql
GRANT SELECT, INSERT, UPDATE, DELETE ON wordpress_db.* TO 'wp_user'@'localhost';
FLUSH PRIVILEGES;

Do NOT grant: CREATE, DROP, ALTER, INDEX unless necessary (e.g., during plugin installation).

Move Database Off Shared Server

For high-security sites, use a separate database server:

Reduces attack surface
Isolates database from web server compromise
Enables separate backup strategies

—

Step 4: Secure the WordPress Admin

Two-Factor Authentication (2FA)

For all admin accounts. No exceptions.

Plugin options:

Wordfence Login Security (free)
Two Factor (official WordPress plugin)
Google Authenticator by MiniOrange

Enforce for all users:

php
// Require 2FA for administrator role
add_action('wp_authenticate', function($user) {
    if (in_array('administrator', $user->roles)) {
        // Check 2FA status
    }
});

Admin IP Restrictions

Limit admin access to specific IPs:

.htaccess method:

apache

    Require ip 192.168.1.100
    Require ip 10.0.0.0/24

Nginx method:

nginx
location /wp-admin {
    allow 192.168.1.100;
    deny all;
}

Force Strong Passwords

Add to functions.php or a functionality plugin:

php
add_filter('wp_min_password_strength', function() {
    return 4; // Require "Strong" password
});

—

Step 5: Server-Level Hardening

Hide WordPress Version

Remove the WordPress version number from source code:

php
// Remove generator meta tag
remove_action('wp_head', 'wp_generator');

// Remove version from RSS feeds
add_filter('the_generator', '__return_empty_string');

// Remove version from scripts/styles
add_filter('style_loader_src', 'remove_version_strings');
add_filter('script_loader_src', 'remove_version_strings');

function remove_version_strings($src) {
    if (strpos($src, 'ver=')) {
        $src = remove_query_arg('ver', $src);
    }
    return $src;
}

Security Headers

Add these headers via .htaccess or server config:

apache

    Header always set X-Content-Type-Options "nosniff"
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set X-XSS-Protection "1; mode=block"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
    Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"

Nginx equivalent:

nginx
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Disable Directory Indexing

Prevent visitors from browsing your file structure:

.htaccess:

apache
Options -Indexes

Nginx:

nginx
autoindex off;

—

Step 6: Backup Strategy (Your Insurance Policy)

Even with perfect hardening, assume you’ll be hacked. Your backup is your insurance.

The 3-2-1 Backup Rule

3 copies of your data
2 different storage media
1 offsite location

Recommended Backup Schedule

Component	Frequency	Retention
Full site files	Weekly	4 weeks
Database	Daily	30 days
wp-content/uploads	Real-time (if possible)	90 days
wp-config.php	Before every change	Indefinite

Backup Tools

Plugin-based:

UpdraftPlus (most popular, reliable)
BlogVault (good for multisite)
Jetpack Backup (automated, requires Jetpack)

Server-level:

Automated cron jobs with mysqldump + rsync
Snapshot backups (if using VPS/cloud hosting)
Cloud provider backups (AWS, DigitalOcean, etc.)

Test Your Backups

A backup you can’t restore is worthless. Test restoration:

Spin up a staging environment
Restore from backup
Verify everything works
Document the process

Test quarterly. Not annually, not “when you remember.” Quarterly.

—

Step 7: Monitoring and Incident Response

Security Monitoring Tools

Wordfence: Real-time threat detection, firewall blocking, login attempt monitoring.

Sucuri Scanner: Remote malware scanning, blacklist monitoring, security notifications.

iThemes Security: File change detection, brute force protection, database backups.

Set Up Alerts

Configure notifications for:

Failed login attempts (more than 5 in an hour)
File modifications outside of updates
Plugin/theme installations
Admin user creations
Database changes outside normal hours

Incident Response Plan

When (not if) a security incident occurs:

Contain: Take site offline or restrict access
Assess: Identify what was compromised
Eradicate: Remove malicious code, backdoors, compromised accounts
Restore: From clean backup if necessary
Verify: Confirm site is clean (use multiple scanners)
Learn: How did they get in? Fix the vulnerability
Monitor: Increased vigilance for 30 days post-incident

—

Security Hardening Checklist

Critical (Do These Now)

[ ] Install and configure Wordfence or Sucuri
[ ] Enable 2FA for all admin accounts
[ ] Change default login URL
[ ] Disable XML-RPC
[ ] Set strong file permissions (never 777)
[ ] Secure wp-config.php (move above web root or restrict access)
[ ] Disable file editing in admin
[ ] Implement daily automated backups
[ ] Add security headers
[ ] Hide WordPress version

Advanced (Do These Next)

[ ] Change database table prefix
[ ] Restrict database user privileges
[ ] Implement rate limiting on wp-login.php
[ ] Enable server-level IP restrictions for admin
[ ] Set up fail2ban or equivalent
[ ] Configure Web Application Firewall (WAF) rules
[ ] Implement Content Security Policy (CSP)
[ ] Enable HTTP Strict Transport Security (HSTS)
[ ] Set up file integrity monitoring
[ ] Document incident response plan

Ongoing Maintenance

[ ] Weekly: Review security plugin logs
[ ] Monthly: Check file permissions
[ ] Monthly: Verify backup integrity
[ ] Quarterly: Test backup restoration
[ ] Quarterly: Review user accounts and privileges
[ ] Quarterly: Audit installed plugins for unused/abandoned ones
[ ] Immediately: Patch when critical vulnerabilities announced

—

Conclusion

WordPress security isn’t a destination — it’s a process. The threats evolve daily, and yesterday’s secure configuration might not hold against tomorrow’s attack.

Start with the critical checklist. Get the fundamentals right first: strong passwords, limited login attempts, file permission control, and reliable backups. Then layer on advanced protections: 2FA, IP restrictions, database hardening, and monitoring.

The most important security principle: Assume you’ll be compromised. Your preparation determines whether it’s a 10-minute restore from backup or a 10-hour disaster recovery.

Stay vigilant. Stay updated. Stay backed up.

—

Last updated: April 2025

WordPress Security Hardening: Advanced Protection Beyond the Basics

WordPress Security Hardening: Advanced Protection Beyond the Basics

Why Basic Security Isn’t Enough

The WordPress Attack Surface

Step 1: Lock Down wp-login.php

Change the Login URL

Implement Rate Limiting

Disable XML-RPC

Step 2: Harden File Permissions

Correct Permission Structure

Secure wp-config.php

Disable File Editing

Step 3: Database Security

Change Database Table Prefix

Restrict Database User Privileges

Move Database Off Shared Server

Step 4: Secure the WordPress Admin

Two-Factor Authentication (2FA)

Admin IP Restrictions

Force Strong Passwords

Step 5: Server-Level Hardening

Hide WordPress Version

Security Headers

Disable Directory Indexing

Step 6: Backup Strategy (Your Insurance Policy)

The 3-2-1 Backup Rule

Recommended Backup Schedule

Backup Tools

Test Your Backups

Step 7: Monitoring and Incident Response

Security Monitoring Tools

Set Up Alerts

Incident Response Plan

Security Hardening Checklist

Critical (Do These Now)

Advanced (Do These Next)

Ongoing Maintenance

Related Articles

Conclusion

more posts:

WordPress Migration Guide: How to Move Hosts Without Downtime

WordPress Database Optimization: How to Fix Slow Queries

n8n WordPress Automation: 5 Workflows That Save 10+ Hours/Week