WordPress powers a significant proportion of all live websites, which makes it a profitable target for automated attacks. Attackers run bots that scan for WordPress installations and probe them for known vulnerabilities in core files, plugins, and themes. Most of these bots are not sophisticated — they are looking for a way in, any way in, and they find it in sites with default settings left unchanged.
The most common entry points are default settings, outdated plugins with known exploits, weak passwords on admin accounts, and publicly accessible files that should not be exposed. This article covers the specific configuration changes that remove those entry points and reduce the attack surface of a WordPress installation.
Restrict wp-admin Access by IP
The wp-admin directory is the highest-value target on any WordPress site. Restricting access to it by IP address is one of the most effective hardening steps available, and it takes about five minutes to configure.
In the .htaccess file inside the wp-admin directory, add rules that allow only your trusted IP addresses:
Order deny,allow
Deny from all
Allow from 203.0.113.42
Allow from 198.51.100.15Replace the example IPs with your actual office or home IP addresses. A static IP from your ISP is needed for this to work reliably. If your ISP uses dynamic IPs, consider using a VPN that provides a static IP for admin access instead.
For sites that need wp-admin access from many locations, IP restriction may not be practical. In that case, require VPN access before the WordPress login page rather than exposing wp-admin directly to the internet.
Rename the Admin Account
WordPress default installation creates an admin account with the username admin. Every bot attempting a brute-force login knows this username. Changing it to something non-obvious removes one piece of information from the attacker's toolkit.
You cannot change a username through the WordPress admin panel, but you can change it through the database. Run this SQL query against your WordPress database, replacing newadmin with your chosen username and admin with the existing default:
UPDATE wp_users SET user_login = 'newadmin' WHERE user_login = 'admin';After renaming, create a new account with a different email address and the administrator role, then delete the old admin account. WordPress will prompt you to attribute all posts to the new account when you delete the old one.
This step alone will not stop a determined attacker who has obtained your username through other means, but it stops the automated bots that expect the admin account to exist with its default name.
Change the Database Prefix
WordPress default table prefix is wp_. SQL injection attacks that rely on predictable table names are simplified when the prefix is unchanged. Change it to something random like wpx7k2_ in the wp-config.php file during installation, or use a security plugin that changes it on an existing site.
Changing the prefix on an existing site requires a database migration script and must be done carefully. Attempting to change it manually without a tool designed for the purpose risks breaking the site. Take a full database backup before attempting any prefix change on a live site.
Disable XML-RPC
XML-RPC is a WordPress feature that allows external applications to interact with your site via HTTP requests. It is enabled by default and provides multiple authentication vectors that attackers have exploited in distributed brute-force attacks.
If you do not use WordPress mobile apps, the Jetpack plugin, or any service that requires XML-RPC, disable it by adding this to your .htaccess file:
Require all denied
If you do need XML-RPC for Pingbacks, the WordPress mobile app, or certain automation tools, install a plugin that allows you to disable specific XML-RPC methods rather than disabling the entire endpoint.
File Permissions
WordPress files should be owned by the web server user and readable by the server, but not writable by the server process itself. The uploads directory is the exception — it must be writable in order to accept uploaded files from the media library.
Set directory permissions to 755 and file permissions to 644 across the WordPress installation. The uploads directory should remain 755. Check the file ownership and permissions after any plugin or theme update, as some update processes change permissions incorrectly.
The wp-config.php file deserves particular attention. It should be set to 440 or 400 — readable by the owner and the group, not writable by anyone else, and not readable by the public. If your hosting environment uses a different web server user than the file owner, this may require coordination with your host.
Disable PHP Execution in Uploads
The most common exploitation path for a vulnerable plugin is uploading a PHP file to the uploads directory and then requesting it directly to execute code on the server. Preventing PHP execution in uploads blocks this attack even if a file upload vulnerability exists.
Create an .htaccess file inside wp-content/uploads with these rules:
Require all denied
This blocks direct execution of any PHP file uploaded to the uploads directory. WordPress does not need to execute PHP in uploads — it only needs to store and retrieve files there.
Protect wp-config.php
The wp-config.php file contains your database credentials, security keys, and other sensitive configuration data. It should be one of the most protected files on your server.
Beyond setting correct file permissions, move the wp-config.php file one directory above your WordPress root if possible. WordPress will look for it in the parent directory by default. This places it outside the publicly accessible web root, making it harder for an attacker to access even if they find a way to read files on the server.
Also ensure your security keys are set in wp-config.php. These keys are used to encrypt cookies and session data. If they are left as the default empty values, sessions can be hijacked more easily.
define('AUTH_KEY', 'put your unique phrase here');
define('SECURE_AUTH_KEY', 'put your unique phrase here');
define('LOGGED_IN_KEY', 'put your unique phrase here');
define('NONCE_KEY', 'put your unique phrase here');
define('AUTH_SALT', 'put your unique phrase here');
define('SECURE_AUTH_SALT', 'put your unique phrase here');
define('LOGGED_IN_SALT', 'put your unique phrase here');
define('NONCE_SALT', 'put your unique phrase here');Use the WordPress API key generator to create strong, random values for each of these constants.
Enforce Strong Passwords and Limit Login Attempts
Weak admin passwords remain one of the easiest ways into a WordPress site. Enforce strong passwords for all user accounts with administrator or editor roles. A strong password should be at least 12 characters and include a mix of uppercase, lowercase, numbers, and special characters.
Beyond strong passwords, limit the number of login attempts allowed from a single IP address. Without this, attackers can attempt unlimited password combinations against your login form until they find a match. This can be handled at the server level using a tool like Fail2Ban, which monitors log files and temporarily bans IPs that show brute force patterns.
For sites running on Ubuntu, setting up Fail2Ban with rules tuned for WordPress login failures provides an additional layer of protection that works independently of any WordPress plugin. There are published guides covering Fail2Ban Ubuntu web server setup that walk through the installation and configuration process.
Two-Factor Authentication for Admin Accounts
Even with strong passwords, adding a second authentication factor significantly reduces the risk of unauthorised access. Two-factor authentication requires something you know (your password) and something you have (a code from an authenticator app or hardware key).
Several WordPress plugins provide two-factor authentication functionality. When choosing a plugin, prefer one that supports time-based one-time passwords (TOTP) or hardware security keys rather than SMS-based codes, which can be intercepted through SIM swapping.
Enable two-factor authentication for every account with administrator privileges. It takes a few minutes to set up per account but makes credential-based attacks substantially harder to execute.
Keep Everything Updated
A WordPress hardening configuration that was solid six months ago is incomplete if the plugins it depends on have not been updated since. Plugin and theme vulnerabilities are discovered regularly, and updates often patch known security issues.
Enable automatic updates for WordPress core if your site can tolerate minor version updates automatically. For plugins and themes, review each update before applying it on production sites, particularly if the update includes security patches — those should be applied promptly.
Set up a schedule to review your installed plugins and themes. Remove any that are no longer maintained by their developers or that you no longer use. Unused code on the server is an unnecessary attack surface, even when it is not active.
Server-Level Hardening Considerations
WordPress hardening at the application level works best when the server it runs on is also properly configured. The web server software itself — whether Apache, Nginx, or another — has settings that affect how secure your site is.
For sites running Apache, reviewing the server configuration for exposure of sensitive files, incorrect directory listings, and missing security headers is worth the time. There are specific Apache security configuration settings that affect how well your server resists common attack patterns.
At a minimum, ensure the web server runs with a limited user account, disables directory browsing, and does not serve files outside the intended web root. These are basic server hardening steps that apply regardless of what CMS you are running.
Hosting Environment and Security
The hosting environment your WordPress site runs on has a direct impact on its security posture. Shared hosting environments, where multiple sites share the same server resources and user permissions, can allow vulnerabilities in one site to affect others on the same server.
Cheaper hosting plans often come with fewer security controls, less isolation between accounts, and limited ability to implement server-level hardening measures. If your site handles sensitive data or is critical to your business, the cost savings from budget hosting may come with security trade-offs that are worth considering carefully.
For business-critical WordPress sites, a VPS or dedicated server with root access gives you more control over the security configuration and allows you to implement measures like those covered in this guide without being constrained by shared hosting limitations.
Regular Security Reviews
Hardening your WordPress site is not a one-time task. Security threats evolve, new vulnerabilities are discovered in plugins and themes, and your own configuration may drift over time as you add new functionality or change hosting arrangements.
Schedule periodic reviews of your security configuration. Check that file permissions have not changed, that all user accounts still need their access levels, that updates are being applied consistently, and that no new plugins with poor security track records have been installed.
For a more thorough assessment, a WordPress security audit examines the full configuration, identifies potential vulnerabilities, and provides recommendations based on your specific setup and threat profile.
WordPress Hardening Summary
The steps covered in this article address the most common automated attack vectors against WordPress sites: credential guessing, predictable admin URLs, exploited plugins, and file-based code execution. They do not require expensive plugins or enterprise hosting. They require a few configuration changes and ongoing discipline around keeping plugins and themes updated.
The key hardening measures are restricting wp-admin access by IP, renaming the default admin account, changing the database prefix, disabling XML-RPC if not needed, setting correct file permissions, preventing PHP execution in uploads, protecting the configuration file, and enforcing strong authentication across all admin accounts.
Combine these application-level measures with server hardening where possible, keep everything updated, and review your security configuration periodically. This approach reduces the attack surface substantially and makes your WordPress site significantly harder to compromise through automated means.