10 WordPress Security Hardening Protocols

1. Disable the XML-RPC API

XML-RPC is a legacy feature that allows external applications to talk to WordPress. Today, it is primarily used by bots to execute massive brute-force attacks and DDoS amplification.

• The Fix: If you aren’t using the Jetpack or the WP Mobile app, disable it via .htaccess or your NGINX config. Even better, use a filter: add_filter( 'xmlrpc_enabled', '__return_false' );.

2. Rename the Database Prefix

The default wp_ prefix is a roadmap for SQL injection attacks. Automated scripts target wp_users and wp_options specifically.

• The Fix: Change your prefix to something random like shf_782_. Do this during installation or use a tool like WP-CLI to rename existing tables and update the wp-config.php and the options table.

3. Move the Login URL

Bots relentlessly hit wp-login.php and wp-admin. Even if they don’t get in, the constant POST requests spike your server’s CPU.

• The Fix: Use a constant or a lightweight plugin to change the login slug to a custom string. This hides the “front door” from 99% of automated scanners.

4. Disable File Editing in Dashboard

The built-in theme and plugin editor is a catastrophic security risk. If an attacker gains admin access, they can inject malicious PHP directly into your files via the dashboard.

• The Fix: Add define( 'DISALLOW_FILE_EDIT', true ); to your wp-config.php. This disables the editor entirely.

5. Enforce Strong Security Keys (Salts)

Salts encrypt the information in user cookies. If your site was migrated or poorly installed, your salts might be default or old.

• The Fix: Go to the official WordPress Salt Generator and replace the eight keys in your wp-config.php. This instantly invalidates all active sessions, forcing a re-login and killing any hijacked cookies.

6. Disable Directory Browsing

By default, if a folder doesn’t have an index.php file, some servers will list all files in that directory. This allows hackers to map your plugin versions and find vulnerabilities.

• The Fix: In NGINX, ensure autoindex off; is set. In Apache, add Options -Indexes to your .htaccess.

7. Restrict REST API Access

The WP REST API is powerful but can leak user data (like usernames) to unauthenticated requests.

• The Fix: Unless you are running a headless setup, restrict the REST API to only logged-in users or specific endpoints using the rest_authentication_errors filter.

8. Hardened Header Security

Use the server to tell the browser how to behave. Implementing security headers prevents XSS (Cross-Site Scripting) and Clickjacking.

• The Fix: Add X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN, and Content-Security-Policy to your NGINX or Apache headers.

9. Protect wp-config.php and .htaccess

These are the most sensitive files in your installation. They should not be accessible via a browser.

• The Fix: Add specific deny rules in your server config. For NGINX: location ~* wp-config.php { deny all; }

10. Limit Login Attempts at the Firewall

Don’t let the application handle brute-force protection. By the time WordPress “blocks” a user, the PHP process has already run.

The Fix: Use Fail2Ban at the server level or Cloudflare WAF rules to block IPs after 3-5 failed attempts before they even reach your WordPress install.