Hardening your website’s security

Table of Contents

• Introducing WordPress Hardening
• Hardening – Basic
  • Disable “anyone can register”
  • Disable the built-in file editors
  • Prevent code execution in the public ‘Uploads’ folder
  • Hide your WordPress version
  • Prevent login feedback
  • Disable directory browsing
  • Disable user enumeration
  • Block the ‘admin’ username
  • Disable XML-RPC
  • Block user registrations when login and display name are the same
• Hardening – Advanced
  • Disable HTTP methods
  • Rename and randomize your database prefix
  • Change debug.log file location
  • Disable application passwords
  • Restrict creation of administrator roles
  • File permissions check
  • Custom Login URL
  • XML-RPC Policy Generator
  • File Change Detection

Introducing WordPress Hardening

In our first article in the Tips & Tricks series, we elaborated that WordPress Core is highly secure on it’s own, but that it is still possible for vulnerabilities to exist on your WordPress environment. Certain features in WordPress can pose a security risk if they are not configured appropriately, which is where the Basic and Advanced Hardening features in Really Simple Security (located under SSL & Security -> Settings -> Hardening) come into play.

Hardening your WordPress site refers to the implementation of additional security measures to reduce your site’s vulnerability to common attack vectors. This can involve removing unnecessary code & functionality that is not in use, or enforcing stricter limits on the attempts to use or manipulate a system. The goal is to make it more difficult for an attacker to successfully compromise a website, and to minimize the damage that can be caused if an attack were to succeed.

In this article, we will explain what each of the Hardening features in the plugin does, and how they contribute to a more secure WordPress environment. We differentiate between Basic and Advanced Hardening. The key difference is that Basic Hardening addresses the most common security needs that apply to most WordPress sites, whereas Advanced Hardening provides more specialized protection that might require some additional configuration. Let’s start with the Basic hardening features.

Hardening – Basic

The “Basic” hardening functionalities include fundamental security measures that are essential for most WordPress sites. These features address common vulnerabilities and best practices that most sites should implement.

Disable “anyone can register”

This deactivates the “anyone can register” checkbox located under Settings -> General in WordPress, and prevents it from being enabled (while this setting is active in Really Simple Security).

The “anyone can register” setting in WordPress allows all visitors to register an Account on your website, and can result in excessive amounts of spam comment submissions/user registrations. If you do not require users to register an Account on your website, enabling this option is recommended.

Disable the built-in file editors

Direct file editing via the WordPress Admin Dashboard is not recommended as it represents an unnecessary risk, especially on production environments. If an attacker gains access to an admin account, they could potentially use these editors to inject malicious code directly into your theme or plugin files.

However, even legitimate users can accidentally introduce issues when editing core files directly, such as causing a Fatal Error or breaking site functionality. Disabling these editors encourages users to make changes through proper development workflows, rather than by editing live files.

This setting therefore removes the ability to edit Theme and Plugin files directly from the WordPress Admin Dashboard, by disabling the Theme File Editor (under Appearance) and the Plugin File Editor (under Plugins) that are located in the left-hand sidebar by default.

Prevent code execution in the public ‘Uploads’ folder

This setting blocks the execution of PHP files in the /uploads/ directory. While uploading .php files to the uploads folder is blocked by default, if that protection were to somehow be circumvented, this additional mechanism prevents the code in that folder from being executed.

Before activating:

After activating:

Note: this functionality is only supported on Apache & LiteSpeed servers.

Hide your WordPress version

Information about the WordPress version that your website uses can be useful for a potential attacker, as it allows them to determine whether your specific WordPress version contains any known security vulnerabilities that they can try to exploit. Enabling this setting in Really Simple Security removes the information about your current WordPress version from the page source of the website.

This makes it more difficult for an attacker to accurately determine the WordPress version that your website uses, and if there are any security vulnerabilities present in your version of WordPress which they might be able to exploit.

Prevent login feedback

Login feedback on your Admin Dashboard, such as “The password you entered for the username […] is incorrect”, can be helpful to know which one of the fields contained invalid input that should be corrected. However, this information is also very useful for hackers, as it allows them to determine whether they have correctly ‘guessed’ the username of an existing account on your WordPress site.

For instance, when entering a correct username of an existing account on your site, but supplying an invalid password for that account; WordPress informs you that the password you entered does not match the one that is configured for that user.

However, if the supplied username does not exist on your site at all, the following message will appear instead:

This allows an attacker to test whether a user account exists by submitting repeated login attempts with various usernames, since WordPress will inform them when they’ve entered a correct username (but with an invalid password); or if the user does not exist on the site.

It is therefore recommended to disable this login feedback to prevent malicious actors from being able to use this information to their advantage. Enabling this setting in Really Simple Security replaces the default login feedback with more generic warnings which do not ‘leak’ details of user accounts on your site.

Disable directory browsing

This setting prevents visitors from viewing or browsing through the contents of directories on your server. It avoids potentially leaking sensitive information by blocking access to files and folders that were not intended to be publicly visible.

Enabling this setting will create an index.html file in all of your folders to prevent directory browsing. While many hosting providers will apply configurations to prevent this by default, activating this feature in Really Simple Security ensures that the protection is in place regardless of your host’s settings.

Disable user enumeration

WordPress automatically generates author pages for each registered user (e.g., example.com/?author=1). Potential attackers can exploit this feature to enumerate users on your website by iterating through numerical IDs in the author URL. When visited, these pages redirect to the corresponding author’s page, revealing their username.

Activating the “Disable user enumeration” setting will block any requests to the Author ID URLs, which prevents unauthorized users from easily discovering the usernames of registered accounts on your WordPress site. This greatly reduces the risk of targeted attacks and brute-force attempts.

Before activating:

After activating:

Block the ‘admin’ username

Most hosting providers provide you with a tool that automatically installs WordPress on your server, allowing you to quickly get started without having to manually upload WordPress and create a database. However, some of these WordPress installation tools use the username ‘admin’ for the initial Administrator account by default; which is widely known and frequently targeted by attackers in brute-force attempts.

This setting renames the current user with the username ‘admin’ (if it exists), and allows you to select a new username for that account. Enabling this setting also prevents the creation of any new users with the ‘admin’ username.

An e-mail containing the newly configured username will be sent to the e-mail address associated with the “admin” account. Admins can always log in by using their existing email address as the username. If you’ve renamed the admin user with this setting, but happened to forget the newly configured username as well as the e-mail address linked to the account; please see the instructions in this article on how to regain access after renaming the ‘admin’ username.

Disable XML-RPC

XML-RPC is a protocol that allows for communication between WordPress and other systems, to allow for features such as remote publishing and editing of posts. It has been part of WordPress since early versions of the software, and it is still available in current WordPress versions.

However, its functionality has largely been replaced by the more modern & secure WordPress REST API. Most WordPress sites do not require XML-RPC to operate as intended.

Enabling XML-RPC does not mean that your site is guaranteed to be hacked, but it does introduce security risks:

• Brute Force Login Attacks: Malicious actors might be able to exploit XML-RPC to attempt multiple login combinations, potentially bypassing security measures designed to detect and block brute force attempts.
• Denial of Service Attacks: The pingback feature of XML-RPC (to allow websites to notify each other when they’ve been linked to) can be misused in distributed Denial of Service (DDoS) attacks.

You can use a WordPress XML-RPC Validator to check if XML-RPC is currently enabled on your WordPress website. If you see a green checkmark and a “Congratulations!” message when testing your site, it means that XML-RPC is enabled on your site.

• If your website does not require the use of XML-RPC, we recommend using the “Disable XML-RPC” setting in Really Simple Security to disable it and eliminate these attack vectors altogether.
• If your site does require XML-RPC for legitimate purposes, use the XML-RPC Policy Generator (Hardening -> Advanced) to create a policy that specifically allows certain XML-RPC requests.

Block user registrations when login and display name are the same

The display names of your users can be found quite easily on a WordPress website. For instance, the Author of a blog post will have their name displayed near the top of the blog post, and in the RSS feed.

This means that if you allow users to configure a Login username that is identical to their Display name, anyone would be able to see the login username of their account. Ideally, there should be no direct link between the Login username and Display name.

To enforce this requirement, you can activate the“Block user registrations when login and display name are the same” setting. This prevents user registrations where the login username & display name are the same, and the plugin will notify you about any existing user accounts that already have an identical username/display name configured.

Hardening – Advanced

The “Advanced” Hardening features in Really Simple Security include more complex and specialized measures. These require more careful consideration before enabling as they might require additional configuration, and could potentially have an impact on site functionality. These are designed for users who are comfortable with more technical adjustments to their WordPress environment.

Disable HTTP methods

You can further reduce your site’s attack surface by disabling less common HTTP methods. Activating this setting limits the available HTTP methods to GET, POST, HEAD, and OPTIONS. These are the most commonly used methods for standard WordPress operations. Other methods such as PUT, DELETE, TRACE, and PATCH are typically not necessary for a standard WordPress installation.

However, some plugins might require one of these methods. For example, certain plugins that implement webhook functionality might expect to receive PUT requests. Therefore it is recommended to verify whether you have any plugins that require these methods, before activating this setting.

So, while this restriction might interfere with some advanced plugins that rely on certain HTTP methods: for most WordPress sites, disabling unused HTTP methods provides an additional layer of security with minimal impact on functionality.

Rename and randomize your database prefix

By default, WordPress uses ‘wp_‘ as the prefix for all its database tables, and that predictability could be useful to a potential attacker. For instance, many SQL injection attacks target common table names like ‘wp_users‘, and changing the database prefix can make these automated attacks less effective.

Changing the database prefix should be seen as a “Security through Obscurity” measure, and not as a direct solution to prevent vulnerabilities. However, it does offer several security benefits that can be useful, mainly against automated and less sophisticated attacks.

Note: Really Simple Security performs various checks to ensure that it can safely change the database prefix on your environment, but we would always recommend ensuring that you have a working back-up prior to enabling the feature.

Change debug.log file location

If you have Debugging enabled on your site, WordPress will write debug information to a file named debug.log which is located in the /wp-content/ directory by default. This file can contain sensitive information about your WordPress installation, such as server paths, PHP errors, database queries; and sometimes even usernames or other potentially sensitive data.

Because of the debug.log file’s sensitive nature, using the default location for this file could pose a security risk. If an attacker knows where to look, they might be able to download and analyze the debug.log file from your site. This would provide the attacker with detailed information about your site’s structure, active plugins and more.

Enabling this setting in Really Simple Security results in the creation of a folder with a randomized name, and moves the debug.log file to this new, non-standard location. The plugin also updates the WordPress configuration to write future debug information to this new location.

Disable application passwords

Application Passwords are special passwords designed for use by automated processes (such as programs, other websites, or scripts). These passwords allow authentication against the WordPress REST API or XML-RPC without using a user’s main account password, but they do not allow you to login to the User’s actual account.

By default, all user roles are able to create application passwords that are linked to their user account via their Profile page (Users -> Profile) on the WordPress Dashboard. As application passwords remain valid even when a user changes their main account password, and are often overlooked when reviewing account security; this could result in unintended access to the REST API and XML-RPC.

If you’re not actively using Application Passwords for any legitimate purposes (for example, to connect your site to third-party services/tools), you can enable this setting in Really Simple Security to prevent the generation of new application passwords, and revoke existing application passwords across all user accounts.

Restrict creation of administrator roles

A common tactic used by attackers when compromising a WordPress site involves creating new account(s) with Administrator privileges. This would grant the attacker with persistent access to the site, allowing them to make further malicious changes.

The “Restrict creation of administrator roles” setting counters this threat by preventing the creation of administrator roles outside of the standard WordPress interface. Enabling this feature significantly reduces the risk of an attacker maintaining long-term access to your site, if they manage to successfully exploit a vulnerability.

This functionality monitors any attempts to assign the admin role to a user through non-standard methods, automatically demotes users to the Subscriber role if they were granted admin privileges through irregular means, and notifies the Site Administrator by e-mail to alert them of the attempted privilege elevation.

File permissions check

Every file and directory on your server has configurable permissions that determine who can read, write, modify, and access them. Overly permissive settings could leave your site vulnerable to unauthorized access and modification. The File Permissions Check helps you maintain secure permissions across your WordPress installation.

When activated, the plugin will perform regular checks to detect files and folders with insecure or non-recommended permissions. If any insecure permissions are detected, a notice will be added to the Dashboard to inform you. If you’ve verified your email address in the plugin’s settings, you will be notified by e-mail as well.

Clicking the “Fix” button in the Dashboard notice will let the plugin attempt to automatically correct the permissions of these items.

If automatic fixes aren’t possible on your environment, click the highlighted “Download” text in the notice to obtain a list of affected files and their locations. You can then adjust the permissions manually (if you’re comfortable making those changes), or ask your Hosting Provider for assistance in doing so.

Custom Login URL

This feature allows you to change the default WordPress login page (/wp-admin/, /wp-login.php) to an URL of your choosing, and redirect anyone trying to access the ‘standard’ login URL to another page on your site, such as a 404 Not Found page. This adds another layer of security through obscurity by making it harder for a potential attacker to locate your login page.

It must be noted that while this feature can deter casual attackers and reduce certain automated threats, it does not guarantee complete protection against a determined attacker who might discover the new login URL through other means.

We therefore recommend viewing this feature as part of a comprehensive security strategy, rather than a standalone solution.

XML-RPC

While you can disable XML-RPC entirely by using the “Disable XML-RPC” setting (located under Hardening -> Basic) if it is not used on your site: you might have a legitimate use case for XML-RPC on your website. And in that case, you can’t disable XML-RPC support entirely without breaking the functionality that relies on it.

In these situations, you can enable “Learning Mode” in the XML-RPC block under Hardening -> Advanced instead. This will report XML-RPC requests that are sent to your WordPress site, so you can allow specific methods to be used, allowing for more granular control over XML-RPC.

Once the methods that you want to allow have been detected in Learning Mode, click Exit to configure which XML-RPC methods are allowed on your site (such as wp.getPosts), and which ones should remain blocked. Finally, click Enforce to apply the new XML-RPC policy to your site.

File Change Detection

When a WordPress site is infected with malware, the malware will often attempt to modify existing files on your server. These malicious modifications typically involve injecting additional malicious code into legitimate files, making it much more challenging to detect and remove all traces of the malicious code. Such malware frequently targets files of trusted plugins or themes, to cleverly conceal it’s malicious code within components that you wouldn’t usually expect to be compromised.

The File Change Detection feature in Really Simple Security allows you to monitor if such unexpected file changes have occurred on your site. This functionality performs daily scans to detect if modifications have been made to .php and .js files on your website, such as your WordPress Core, Plugin, or Theme files.

You will receive an e-mail warning and a notice in the Really Simple Security Dashboard if any unexpected file changes have been detected (excluding file changes that were performed as a result of regular theme/plugin updates via the WordPress Admin Dashboard). If unexpected file changes have occurred, this could be an indication that your site is compromised.