Security Measures in WP Toolkit

WP Toolkit’s Security Measures tab like a Swiss Army knife security tool for your WordPress site. It’s packed with useful tools to strengthen your defences, helping protect against common vulnerabilities, unauthorised access, and potential exploits. 

There are key security measures (the must-haves, always-on-by-default stuff) and recommended security measures (the slightly more advanced, optional extras that can make you even more secure, but you might want to proceed with caution). Some of these changes are reversible if you ever need to backtrack, while others are more permanent. So, before you dive in, it’s smart to back up your site—just in case things don’t go as planned.

But just like a Swiss Army knife isn’t the only tool you’ll ever need, WP Toolkit's security measures aren't the be-all and end-all of site security. Security is a multi-layered approach, and this is why we also have extremely robust firewalls and automated vulnerability patching for WordPress.

All of these tools help improve protection, but you still need to keep an eye out for known vulnerabilities as they arise. For more information on how to stay vigilant about security threats, check out our article on vulnerability detection.

By combining these tools with proactive security practices, you can build a strong, reliable defence for your WordPress site. Ready to get started?

First, we’ll walk through how to locate and apply these security measures in WP Toolkit. Then, we’ll go through each measure in detail, explaining what it does, why it’s important, and whether it can be reverted.

Applying Security Measures

To apply these security measures, follow these steps:

1. Access WP Toolkit:
   • Log in to your cPanel account and open WP Toolkit.
2. Navigate to the Security Measures Tab:
   • Find and click on the "Security Measures" tab within WP Toolkit. This may be exposed by clicking Fix Vulnerabilities if your site has current vulnerabilities.
3. Apply Security Measures:
   • Review the list of available security measures. These measures can be enabled with a simple click, and most are revertable, however some measures cannot be reverted and you should back up if you wish to enable those.
   • Apply the desired measures to enhance the security of your site. WP Toolkit will implement these settings automatically.

---

Key Security Measures

The following security measures are key and should be enabled on all WordPress websites for best security. They will be enabled by default on new WP installations via WP Toolkit and we strongly recommend you keep these on, or enable them if they are not applied.

---

Restrict Access to Files and Directories (cannot be reverted)

What it does: This feature ensures that your WordPress files and directories are set to the appropriate permissions to prevent unauthorised access. Typically, WordPress files should have 644 permissions (readable by everyone but writable only by the owner), and directories should have 755 permissions (readable and executable by everyone, but writable only by the owner). This option automatically corrects any incorrect permissions.

In addition to this, it sets the wp-config.php file—a critical file containing your database credentials—to 600 permissions. This means only the file’s owner can read and write to it, adding an extra layer of security by further restricting access to this sensitive file.

Possible Complications:

• Custom Permissions: If you’ve manually set specific file permissions, enabling this measure may overwrite those. You’ll want to review your settings after applying this if you have custom needs.

Recommendation:

• Ensure Proper Permissions: For most users, this measure is a straightforward way to enforce correct file and directory permissions, reducing the risk of unauthorised access to important files.
• Protect wp-config.php: Given that the wp-config.php file contains sensitive information, applying this measure is a smart way to enhance your site's security by restricting access to this crucial file.

---

Block Directory Browsing (can be reverted)

What it does: By default, if a directory in WordPress doesn’t have an index file (like index.php or index.html), anyone can access and view the contents of that directory by simply entering the URL in a browser. For example, visiting example.com/wp-content/uploads/2021/11 would display a list of all files uploaded in that folder. This can expose sensitive information, such as media files or data you didn’t intend to be publicly visible.

The Block Directory Browsing measure adds a rule to your server configuration that disables directory listings, preventing unauthorised users from viewing the contents of your folders.

Possible Complications:

• None in Most Cases: Blocking directory browsing typically doesn’t impact site functionality since it only prevents users from viewing the contents of directories through a browser. It won't affect normal site operation or plugin functionality.

Recommendation:

• Extra Layer of Security: Even though our servers are already configured to block directory browsing by default, enabling this measure in WP Toolkit provides an extra layer of protection. There’s no harm in enabling it, as the worst-case scenario is that directory browsing is blocked twice.

---

Block Access to wp-config.php (can be reverted)

What it does: The wp-config.php file is one of the most important files in your WordPress installation. It contains sensitive information like your database credentials, security keys, and other critical configuration settings. Blocking access to this file prevents unauthorized users from viewing or modifying its content.

If, for some reason, your server stops processing PHP files, an attacker could potentially view the raw contents of wp-config.php through a web browser. This security measure ensures that the file remains protected, even if there are issues with PHP processing.

This measure works by adding rules to the server configuration (Apache, nginx) to block any direct access to wp-config.php. However, it's important to note that custom .htaccess directives may override this setting, so ensure any manual configurations don't unintentionally expose the file.

Possible Complications:

• Custom Directives: If you have added custom directives in .htaccess or other server configuration files, they might override this measure. Review any custom configurations to ensure the protection remains intact.

Recommendation:

• Essential Security: Blocking access to wp-config.php is a must for securing your WordPress site, as this file contains highly sensitive data. 

---

Disable PHP Execution in Cache Directories (can be reverted)

What it does: Cache directories are used to store static files like HTML, CSS, or images, allowing your site to load faster by reducing server processing time. There should never be any PHP scripts in these directories, as they are meant only for storing cached content.

The Disable PHP Execution in Cache Directories measure adds a rule that prevents any PHP scripts from being executed within these cache folders. This significantly reduces the risk of malicious code being executed from files that may have been improperly placed or uploaded in the cache directory.

Possible Complications:

• Plugin or Theme Compatibility: In rare cases, a plugin or theme might (improperly) store PHP scripts in cache directories. If that happens, disabling PHP execution might cause issues with these plugins or themes. While this is generally bad practice, some poorly coded tools might operate this way.

Recommendation:

• Revert if Needed: If any functionality is broken after enabling this measure (for example, a plugin or theme stops working), you can easily revert the rule and restore access to PHP execution in the affected cache directories.
• Enhanced Security: For most users, this measure won’t cause issues and provides an extra layer of protection by stopping any unexpected PHP code from running in cache directories.

---

Block Access to Sensitive Files (can be reverted)

What it does: The Block Access to Sensitive Files security measure protects your WordPress site by denying access to certain files that could inadvertently expose sensitive information. For example, when you edit the wp-config.php file, your text editor may create temporary backup files like wp-config.php.swp or wp-config.php.bak. These temporary files can potentially expose sensitive data, such as database credentials, if they are publicly accessible.

In addition, this measure blocks access to default WordPress files such as readme.html, license.txt, and wp-config.php.bak. While these files might not seem dangerous on the surface, they should be protected as a general security practice. Blocking access ensures that unintentional copies or redundant files aren’t available to malicious actors.

Possible Complications:

• Minimal Impact: This measure is unlikely to affect the functionality of your website. However, if you use custom scripts or files with similar naming conventions to the blocked files, there is a small chance it could interfere. Be sure to test after enabling.

Recommendation:

• Enhanced Protection: This measure is highly recommended as it secures backup and temporary files that may be generated during file edits. These files could expose sensitive information if left accessible.
• Monitor for Custom Files: After enabling this measure, monitor your site’s functionality, particularly if you have custom files or naming conventions that might overlap with those being blocked.

---

Change Default Administrator’s Username (cannot be reverted)

What it does: WordPress often creates an administrator account with the username admin during installation. This username is commonly targeted in brute-force attacks because it’s predictable. The Change Default Administrator’s Username feature in WP Toolkit eliminates this vulnerability by creating a new administrator account with a randomly generated username and removing the admin user.

How it works:

1. WP Toolkit identifies any admin user with administrative privileges.
2. If found, it creates a new admin account with a random username and transfers all content from the admin user to this new account.
3. The admin user is permanently deleted.

Possible Complications:

• Non-Reversible: Once the username is changed and the admin account is deleted, this action cannot be undone. You will need to use the new administrator username.
• Backup First: Since this change is irreversible, it's important to back up your WordPress site and database before proceeding to ensure you can recover in case of any issues.

Recommendation:

• Backup Required: Before proceeding, always back up your site to avoid data loss.
• Critical Security Measure: Changing the default administrator username is a simple yet effective way to reduce the risk of brute-force attacks.

For further security enhancements, consider using a plugin to:

• Change the Login URL: You can make it harder for attackers to find your login page by changing the default login URL. Check out plugins like All In One Security for this feature.
• Enable 2FA: Adding two-factor authentication (2FA) provides an extra layer of security. Plugins like Google Authenticator can help you set up 2FA.

---

Recommended Security Measures

The following security measures are strongly recommended to be enabled on all WordPress websites, however, may not be appropriate for all sites.

Block Access to xmlrpc.php (can be reverted):

The xmlrpc.php file in WordPress is used for remote communication with your site. It allows for features like remote publishing and connects your site to external applications like the WordPress mobile app and some Jetpack functionalities.

However, because it is a gateway for remote access, it is also a common target for attackers. Blocking access to xmlrpc.php can prevent several types of attacks, particularly brute force and DDoS attacks, which attempt to overload your site or guess passwords through repeated attempts.

Possible Complications:

• Remote Publishing: If you or your users rely on remote publishing features, or if you use WordPress’ iPhone app, blocking xmlrpc.php will disable this functionality.
• Jetpack and Other Plugins: Some plugins and services, like Jetpack, rely on xmlrpc.php to function properly. Blocking this file might break these features.

Recommendation:

• Assess Necessity: If you don’t use remote publishing or rely on features that need xmlrpc.php, it is safe to block this file and is recommended to do so.
• Monitor Impact: After blocking, check the functionality of any connected services or plugins. If necessary, you can revert the block easily through WP Toolkit.

---

Forbid Execution of PHP Scripts in the wp-includes Directory (can be reverted):

The wp-includes directory is a core part of WordPress, containing essential files and libraries that power the platform. By default, it doesn't require the execution of custom PHP scripts (and probably shouldn’t!). Forbidding the execution of PHP scripts in this directory enhances security by ensuring that only the necessary core files run, thereby reducing the risk of malicious code execution in this critical area.

Possible Complications:

• Custom Modifications: If you have custom scripts or modifications placed in the wp-includes directory (which is uncommon and not recommended), this measure will prevent them from executing.
• Plugin Compatibility: Some poorly coded plugins might attempt to place executable scripts in the wp-includes directory. Blocking execution could potentially break these plugins.

Recommendation:

• Standard Practice: For most users, this security measure will not impact site functionality, as the wp-includes directory typically does not require custom script execution.
• Check Customizations: Ensure that no custom scripts or poorly coded plugins rely on executing PHP files from this directory. If issues arise, assess if these scripts can be moved to a more appropriate directory.

---

Forbid Execution of PHP Scripts in the wp-content/uploads Directory (can be reverted):

Similar to the above measure, this security setting prevents the execution of PHP scripts in the wp-content/uploads directory. This directory is where WordPress stores all media files, such as images, videos, and documents, that you upload through the media library.

This carries the same complications as the previous security measure, but in general, you don’t want PHP scripts to execute in this directory and this should ideally be enabled for best security.

---

Disable Scripts Concatenation for WordPress Admin Panel (can be reverted)

Disabling script concatenation prevents WordPress from combining multiple JavaScript and CSS files into single files in the admin panel. While concatenation can improve load times by reducing the number of HTTP requests, it can sometimes be exploited by attackers to inject malicious code or manipulate existing scripts.

Possible Complications:

• Performance Impact: Disabling script concatenation might slightly increase load times in the admin panel because it increases the number of HTTP requests needed to load the page. However, it will not impact front-end performance.

Recommendation:

• Assess Performance: If the performance impact is minimal and you do not rely on the slight speed improvement provided by concatenation, disabling this feature can add an extra layer of security to your admin panel.
• Enable for Security: For sites with heightened security needs, especially those vulnerable to script injection attacks, this measure is recommended.
• Debugging: This setting can also be useful for debugging purposes, as it allows you to see each individual script and style sheet loaded by WordPress.

---

Turn Off Pingbacks (can be reverted):

Turning off pingbacks disables WordPress's ability to notify other websites when you link to their content. While this feature was once popular for tracking backlinks, it has largely fallen out of favor due to its association with various security vulnerabilities, including Distributed Denial of Service (DDoS) attacks and XML-RPC exploits. Additionally, pingbacks are often exploited by spammers to flood sites with unwanted traffic.

Possible Complications:

• Loss of Backlink Notifications: Disabling pingbacks means you won't receive automatic notifications when other sites link to your content, which can be useful for SEO and networking purposes.
• Compatibility with Plugins: Some plugins that rely on pingbacks for specific functionalities may not work as intended with this feature turned off.

Recommendation:

• Evaluate Necessity: In today's web environment, pingbacks are considered outdated and more of a security liability than a benefit. Most modern SEO tools provide better and safer ways to track backlinks.
• Monitor Impact: After disabling pingbacks, monitor your site's functionality to ensure that no critical features are affected.

Disabling pingbacks is a straightforward and effective way to enhance your site's security by protecting against potential DDoS attacks, spam, and other vulnerabilities. In the current web landscape, pingbacks are largely unnecessary and mainly used by spammers, making this measure a smart choice for most WordPress sites.

---

Disable File Editing in WordPress Dashboard (can be reverted):

Disabling file editing in the WordPress dashboard prevents users from editing theme and plugin files directly from the admin area. This measure reduces the risk of malicious code being injected into your site, whether by accident or through unauthorized access.

Possible Complications:

• Convenience: Disabling file editing removes the convenience of making quick changes to theme and plugin files directly from the dashboard. Developers will need to access the site via FTP or a file manager to make changes.
• Development Workflow: For those who frequently make small adjustments or troubleshoot issues through the dashboard, this measure can add extra steps to their workflow.

Recommendation:

• Enhanced Security: For most site owners, the security benefits far outweigh the inconvenience. Preventing file edits through the dashboard ensures that only users with FTP or file manager access can make changes, significantly reducing the risk of unauthorized modifications.
• Best Practice: It is considered a best practice to disable file editing in the WordPress dashboard, especially for live sites, as it adds an extra layer of security.

Disabling file editing in the WordPress dashboard is a simple yet effective security measure that minimizes the risk of malicious code injections. By enforcing this setting, you can help ensure that only authorized users with appropriate access levels can modify critical files, thereby protecting your site from potential threats.

---

Enable Bot Protection (can be reverted):

Enabling bot protection activates security measures designed to block malicious bots from accessing your site. These bots often engage in automated attacks, data scraping, and other harmful activities that can compromise your site’s security and performance.

Possible Complications:

• False Positives: Sometimes legitimate bots, such as search engine crawlers or third-party service bots, may be mistakenly blocked. This could potentially affect your site’s indexing and functionality with certain services.
• Outdated Rules: While WP Toolkit's bot protection includes many common bots, the landscape of bots changes frequently. New SEO bots appear, and some older ones become less relevant, making it necessary to keep these rules updated.

Our Solution: We have already implemented measures to block problematic bots using ModSecurity, which includes a comprehensive and up-to-date set of rules. These rules cover the bots that WP Toolkit aims to block and more, ensuring that your site is protected against a wide range of malicious bot activities.

Recommendation:

• Redundancy: Enabling bot protection in WP Toolkit may be somewhat redundant on our hosting as we have rules are in place server wide. However, you can still enable this measure.
• Monitor Traffic: After enabling bot protection, monitor your site’s traffic to ensure that legitimate bots are not being blocked. Adjust settings as necessary to balance security and functionality.

Enabling bot protection is an additional safeguard against malicious bots that perform automated attacks and data scraping. While our ModSecurity rules already offer robust protection, this measure can still provide an extra layer of security if desired.

---

Block Access to Potentially Sensitive Files (can be reverted)

What it does: This security measure blocks public access to files that could pose a security risk if left exposed on your WordPress website. These files may include log files, shell scripts, and other executables that could contain sensitive information about your site’s configuration or offer a way for attackers to gain unauthorized access. If these files are accessible to the public, they can potentially compromise your site's security by revealing critical information or enabling malicious actions.

Possible Complications:

• False Positives: In rare instances, certain diagnostic or configuration files may need to be accessed by legitimate users or processes. Blocking access could interfere with these operations.
• Plugin Compatibility: Some plugins may rely on reading or writing to specific files that this security measure blocks. If a plugin uses any of the restricted files for functionality, it could break or lose some capabilities.

Recommendation:

• Enhanced Security: For most WordPress users, blocking access to these potentially sensitive files is a critical step in securing the site. It reduces the risk of data leaks or unauthorized access.
• Monitor and Review: After enabling this measure, monitor your site closely to ensure all plugins and processes are functioning correctly. If necessary, you can make exceptions or revert the rule to allow access to specific files that are needed.

---

Block Access to .htaccess and .htpasswd (can be reverted)

Blocking access to .htaccess and .htpasswd files prevents unauthorised users from accessing or modifying these critical configuration files. The .htaccess file is used to manage various server settings, including redirects, access controls, and security rules, while the .htpasswd file is used to store usernames and passwords for basic authentication.

Possible Complications:

• Server Configuration: Some legitimate users or processes might need to read or update the .htaccess file for configuration purposes. Blocking access might interfere with these tasks.
• Plugin Functionality: Certain plugins rely on the ability to modify the .htaccess file to implement security rules, redirects, or other functionalities. Blocking access might cause these plugins to malfunction.

Recommendation:

• Enhanced Security: For most users, blocking access to .htaccess and .htpasswd files is a critical security measure that helps prevent unauthorized modifications and access.
• Monitor and Adjust: After enabling this measure, monitor your site to ensure that necessary functionalities are not disrupted. If needed, adjust the settings to allow legitimate access while maintaining security.

Note: At Kualo, our Apache configuration already restricts direct access to these files by default. This makes some of the WP Toolkit measures redundant on our servers. However, enabling these measures adds an extra layer of security. The only potential downside is that access might be denied twice, which doesn't cause any issues.

---

Block Author Scans (can be reverted)

What it does: Blocking author scans prevents attackers from identifying the usernames of your site’s authors, which could be used in brute-force attacks. Hackers often attempt to discover usernames by scanning for author profiles, using this information to try and crack the corresponding passwords.

Possible Complications:

• Minimal Impact: Blocking author scans typically has no impact on site functionality. It simply prevents access to URLs that use "author=" followed by a number, which is commonly exploited to retrieve usernames.
• No Effect on SEO: This measure won’t impact legitimate access to author profiles through normal site navigation and doesn’t interfere with SEO.

Recommendation:

• Enhance Login Security: While this measure makes it harder for attackers to discover usernames, it's still crucial to use strong, unique passwords and enable additional login security like two-factor authentication (2FA).
• Best Practice: Ensure that your admin username and displayed author name are different. This makes it even more difficult for attackers to guess login credentials.

How it works: This security measure blocks access to URLs that contain "author=" followed by a numeric value, a common technique used in scans to reveal usernames. By preventing these scans, you reduce the chances of an attacker identifying login names, making your site less vulnerable to brute-force attacks.

---

Configure Security Keys (cannot be reverted)

What it does: WordPress uses eight security keys, which are defined in the wp-config.php file, to secure login sessions and protect cookies from being compromised. These keys help encrypt and secure the information stored in cookies for logged-in users, making it harder for attackers to read or hijack the sessions.

By default, these keys are not set, and you'll often see placeholder text like this in a fresh WordPress install:

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' );

The Configure Security Keys feature in WP Toolkit automates this process by generating unique, random phrases and inserting them into the wp-config.php file for you, enhancing the security of your site.

Possible Complications:

• Existing Users Logged Out: If you regenerate security keys on an active WordPress site, all logged-in users will be logged out, as their cookies will no longer match the new keys. While not a security risk, this can be an inconvenience for users who will need to log back in.
• Custom Key Configurations: If you’ve already customized these keys manually or use a specific configuration, regenerating them with WP Toolkit might overwrite those custom settings.

Recommendation:

• Best Practice: It’s considered a best practice to have strong, unique security keys set in your wp-config.php file. If they are not yet configured, enabling this feature will help strengthen the security of your WordPress site.
• No Need to Act if Pre-Randomised: If you see the green tick next to this option, it indicates that your security keys are already set, so you don’t need to apply this measure again.

---

Change Database Prefix (cannot be reverted)

What it does: The database prefix is a string added to the beginning of each table name in a WordPress database, allowing multiple WordPress installations to share a single database without conflicts. By default, WordPress uses the prefix wp_, resulting in tables like wp_posts and wp_users.

Changing the default table prefix to something random is often recommended as a basic security measure. The idea is that automated scripts targeting WordPress sites may assume the prefix is wp_, and changing it can make those attacks less effective. The Change Database Prefix feature in WP Toolkit automatically generates a random prefix and updates the $table_prefix variable in wp-config.php, while renaming all the associated database tables.

Possible Complications:

• Risky Operation: Renaming tables can be risky, especially if certain plugins or themes expect the original prefix. Always create a full backup of your database before proceeding with this change.
• Limited Security Benefit: While changing the prefix can protect against simple automated attacks, it won’t stop a determined attacker. Anyone with access to your database can still list all tables with a simple SHOW TABLES; command.

Recommendation:

• Backup First: Always back up your database before changing the prefix. If anything goes wrong, you’ll have a fallback.
• No Need to Act if Pre-Randomised: If you see the green tick next to this option, it indicates that your database already uses a random prefix, so you don’t need to apply this measure again.