WordPress Security: Why Default Installations Need Hardening

Out of the box, WordPress is built for convenience, not hardened deployment. The login URL, the database table prefix, the default admin account, and the file permission structure all follow patterns that automated attack tools expect by default. Within minutes of a new WordPress site going live, bots are already scanning it for outdated plugins, known plugin vulnerabilities, and misconfigured settings.

This guide covers the practical steps that reduce the most common attack surfaces on a WordPress installation. These steps do not make a site immune to attack, but they make automated exploitation significantly harder and limit the damage a successful breach could cause. If you want a fuller picture of where vulnerabilities typically hide, a WordPress security audit can identify specific risks in your current setup.

Change the Default Admin Username Immediately

The default WordPress admin account uses the username "admin". Attack tools try this first because it is the standard default. Changing it removes one of the easiest ways for an attacker to gain access.

The process takes a few minutes. Create a new user account with a unique username and assign it the Administrator role. Log out of the original admin account, log in with the new account, and delete the old admin account. When prompted, reassign any existing posts to the new account.

This also prevents basic username enumeration. When someone visits https://yourdomain.co.uk/?author=1, a default WordPress installation redirects to the author archive page and exposes the login username in the URL. With a renamed admin account, that enumeration returns nothing useful.

Enforce Strong Passwords Across All Accounts

WordPress sets minimal password requirements by default. Any account on the site, even one with the Subscriber role, is a potential entry point if it uses a weak password and any username enumeration vulnerability exists on the site.

Use a password manager to generate passwords with 20 or more characters of random content. Plugins like Password Policy Manager or WP Hardening can enforce password complexity rules across all user accounts. If your email provider or hosting control panel offers a password generator, use that as well.

The goal is to ensure that no single account can be compromised through a dictionary attack or credential stuffing attempt.

Move the Login URL Away From Default Paths

Bots constantly scan /wp-admin and /wp-login.php on every WordPress site they can find. Changing these URLs to something unique means automated tools cannot locate the login page without knowing the custom address.

The WPS Hide Login plugin handles this cleanly:

Install WPS Hide Login via Plugins → Add New
Activate the plugin
Go to Settings → General → scroll to WPS Hide Login
Set the login URL to something unique like /secure-login or /access
Save changes

Bookmark the new login URL immediately. If you lose it, you can deactivate the plugin via FTP by renaming the plugin directory in /wp-content/plugins/.

Set Correct File Permissions

WordPress needs write access to certain directories for plugin installation, theme updates, and media uploads. It does not need write access to most files or directories. The correct permission structure limits what can be executed or modified:

All directories: 755
All files: 644
wp-config.php: 640 or 600

Apply these recursively from the WordPress root:

find /var/www/html/yourdomain.co.uk -type d -exec chmod 755 {} \;
find /var/www/html/yourdomain.co.uk -type f -exec chmod 644 {} \;
chmod 640 /var/www/html/yourdomain.co.uk/wp-config.php

The wp-config.php file contains your database credentials and authentication keys. It should not be world-readable. The web server user needs to read it, so 640 (owner and group) or 600 (owner only) is appropriate. Setting it to 777 removes all restrictions and creates a serious security risk.

If you are on shared hosting where you do not have shell access, use your hosting control panel file manager or an FTP client to set these permissions manually.

Disable XML-RPC Unless You Need It

XML-RPC allows external applications to interact with your WordPress site, including posting content and handling trackbacks. It is also a frequently exploited attack surface because it can be used for brute-force attacks and pingback enumeration.

Unless you specifically need XML-RPC for the WordPress mobile app, Jetpack, or another integration, disable it by adding this to the .htaccess file in your WordPress root:

<FilesMatch "\.(xmlrpc\.php)$">
    Order Allow,Deny
    Deny from all
</FilesMatch>

If you do need XML-RPC functionality, use a plugin like Disable XML-RPC to require authentication for XML-RPC requests rather than blocking the feature entirely.

Block PHP Execution in Upload Directories

File upload forms are a common route for attackers to place malicious code on a WordPress site. Even with file type validation in place, determined attackers sometimes find ways to upload PHP files to the uploads directory. Blocking PHP execution in that directory means an uploaded shell script cannot run even if it makes it onto the server.

Create a new .htaccess file in /var/www/html/yourdomain.co.uk/wp-content/uploads/ with this content:

<FilesMatch "\.php$">
    Order Allow,Deny
    Deny from all
</FilesMatch>

This prevents any PHP file in the uploads directory from executing, regardless of its filename or file extension trickery used at upload time.

Keep WordPress, Plugins, and Themes Updated

The majority of WordPress compromises trace back to outdated software. A plugin with a known vulnerability is an open door that automated tools will find and exploit. Enabling automatic updates for minor WordPress releases keeps security patches applied without manual intervention:

define('AUTOMATIC_UPDATER_DISABLED', false);
define('WP_AUTO_UPDATE_CORE', 'minor');

The minor setting applies security patches automatically but leaves major version updates for manual testing before deployment. Major releases can introduce breaking changes that affect custom themes or plugins.

For plugins and themes, the Easy Updates Manager plugin gives you fine-grained control over which updates apply automatically. When a security patch is released for any plugin or theme you use, apply it promptly. Waiting weeks or months to update creates unnecessary risk.

Install and Configure a WordPress Security Plugin

Two well-regarded options cover most WordPress hardening needs without conflicting with each other:

  • Wordfence: Provides a web application firewall, malware scanning, login security with two-factor authentication support, and real-time threat intelligence. The free tier is substantial. The firewall requires some configuration to avoid blocking legitimate traffic during the learning period.
  • Solid Security: Focuses on hardening measures including file permission enforcement, database prefix changing, admin username enforcement, and disabling unnecessary features. Formerly known as Better WP Security.

Choose one plugin and configure it properly. Running multiple security plugins simultaneously causes conflicts, duplicate functionality, and can break site functionality or bring down the site entirely. A single well-configured security plugin is more effective than two partially-configured ones fighting each other.

Add Two-Factor Authentication to the Login

Two-factor authentication means that even if someone obtains your password, they cannot log in without a second verification factor. This dramatically reduces the risk from password compromise, phishing, or credential stuffing attacks.

The WP 2FA plugin sets this up cleanly:

Install WP 2FA via Plugins → Add New
Activate the plugin
Go to Users → Two-Factor Options
Enable TOTP (authenticator app) for all administrator accounts
Set a fallback method such as email or backup codes
Test 2FA on your own account before enabling it site-wide

Every administrator account should have two-factor authentication enabled. An administrator account protected only by a password is a single point of failure for the entire site. For a more detailed walkthrough, the two-factor authentication setup guide covers the process step by step.

Change the Default Database Table Prefix

WordPress uses wp_ as the default table prefix for all database tables. SQL injection attacks that specifically target WordPress installations rely on this default prefix. Changing it during installation to something random like wpx7_ or x9k_ breaks those automated attacks.

If WordPress is already installed with the default prefix, you can change it manually by editing the prefix in wp-config.php and running a database update script. Several plugins automate this process. Always back up the database before making any structural changes to it. Restoring from a clean backup is the only reliable recovery path if something goes wrong during the change.

Set Up Monitoring and Alerting

Knowing about a compromise quickly matters. The longer a breach goes undetected, the more damage an attacker can do. A practical monitoring setup includes:

  • Uptime monitoring: Services like UptimeRobot or Pingdom check your site every few minutes and alert you when it goes down or returns errors. This catches outages caused by attacks or server issues.
  • Security logging: Wordfence logs all failed login attempts, file changes, and plugin or theme updates. Review these logs weekly or configure alerts for suspicious patterns such as multiple failed logins from the same IP.
  • Google Search Console: Register your site and Google will notify you if it detects malware or if pages are not indexing correctly. This is free and often catches security issues that affect search visibility before you notice them yourself.

What to Do When WordPress Is Compromised

If you suspect your site has been breached, act quickly and methodically:

  1. Change all passwords immediately: WordPress user passwords, the database password in wp-config.php, your hosting account password, and any FTP or SFTP credentials you use.
  2. Restore from a known-good backup: The backup must predate the compromise and must have been verified clean. Restoring from a backup made after the site was already compromised solves nothing.
  3. Scan for backdoors: Use Wordfence or a tool like maldet to scan local files for shell scripts, encoded payloads, or other signs of a persistent backdoor left by the attacker.
  4. Update everything: Apply the latest versions of WordPress, all plugins, and all themes. Known vulnerabilities should be closed as a first step.
  5. Review user accounts: Check for any administrator accounts you did not create. Attackers often create hidden accounts to regain access after you clean up.
  6. Contact your hosting provider: They may have additional tools, logs, or information about how the compromise occurred and whether other sites on the server were affected.

If you do not have a recent verified backup or are unsure how to clean up safely, working with someone who handles WordPress recovery professionally can reduce the risk of leaving hidden backdoors in place.

WordPress Security Is an Ongoing Practice

Hardening a WordPress site against automated attacks involves multiple layers working together. No single plugin, configuration, or hosting setup guarantees complete security. What the steps in this guide do is raise the bar high enough that automated tools move on to easier targets and that a successful attack causes limited damage rather than complete site compromise.

The habits that keep a WordPress site secure over time are straightforward: apply updates promptly, review logs for unusual activity, maintain clean backups, and revisit the security configuration when adding new plugins or changing the hosting setup. If your site handles sensitive data or is critical to your business operations, a periodic security audit helps catch configuration drift or outdated settings before they become exploitable vulnerabilities.