The WordPress team makes quite a lot of effort to address security. But you must really understand the sheer size and scope of the WordPress ecosystem and the thousands of plugins and themes you can interact with. You cannot realistically hope that it will be fine with so many possible combinations of code instances. Instead, staying alert is a viable strategy that must be included in your development cycle.
Why does it matter
Ignoring security on your WordPress site could lead to a number of aftermaths, which will seriously endanger your reputation and could drag you through unfavourable legal consequences. This applies to the web designers/developers/agencies as well - imagine how you would look if a client’s website is hacked.
We can classify attacks into many categories, but I mostly observed they fall into two distinct use cases, manual and automated attacks. They differ in goals:
Manual way involves somebody using his mental capacity to actively hack your site, by using a number of methods. Very often these include stealing passwords or hosting access data. Only seldom do they depend on a commonly known WordPress vulnerability. And the goal could lie anywhere between the attacker having fun, stealing personal data and/or blackmailing the site owner. You could do some steps (as we mention below) to limit hacker’s potential quite significantly.
Automated way happens when automated bots are trying to scan thousands of sites for a specific vulnerability, typically a narrow attack vector. Most usually the goal here is to infect the site with malicious code which does something nasty when your webpage is opened. This attack tendency is more specific, could be adequately identified and thus can be somehow prevented by proper tools.
Let’s explore WordPress security solutions as a series of steps.
01: Start by access
Before we even start with WordPress, make sure that your development environment is safe. Once you expose passwords in any way and they are infiltrated on your PC, any steps following from here do not matter.
If hosting access details are not secure, consider your site lost. Anybody with working FTP / SFTP access to the site can basically access anything they desire.
Make sure you have a secured way of storing passwords, and ideally avoid distributing passwords to anybody completely, as the communication channel could be compromised on the other end.
It’s a good practice that everybody who has access to WordPress admin uses a separate account, for which only they know the password. This also helps later when you try to diagnose problems, as having distinct users visible in the logs is great for a security analysis following some security problems.
02: Hosting
Once you put your site on a hosting plan, make sure you choose an option working well with WordPress. It is a good sign if your provider recommends the hosting plan for WordPress, or even has some easy way to automatically spawn a new installation.
WordPress is built on PHP and it makes sense to use the latest possible PHP version. Older PHP versions age fast, and once they are taken out of the security update cycle there is no guarantee they will be safe. And language-based vulnerabilities tend to be the most serious.
You could never go wrong if you choose WordPress-optimized managed hosting. They cost more but offer unmatched possibilities to make development easier while attaining a high level of security and performance. We recommend Kinsta as an absolutely cutting-edge solution, WP Engine is also well known. Best optimized hostings also provide a way to counter DDoS attacks, which is probably the most evil method your site could be targeted with.
03: WordPress core
The advice here is easy: always update to have as recent WordPress core as possible.
The update system that WordPress uses is miles ahead of other CMS such as Drupal. WordPress employs an automatic update scheme for quite some time. By default, only minor updates are automatically received, which is the third number in a version, such as 4.9.2. They usually contain security fixes and are non-breaking, but that also means that most sites stick with their major version. Which is confirmed by official stats.
As WordPress core rarely breaks backwards compatibility, we recommend upgrading core as high as possible. Of course, any major update needs to be properly tested beforehand, ideally in a staging environment. Large-scale changes, such as the addition of Gutenberg editor, could be an issue when upgrading, but ultimately the rewards highly outweigh the negatives.
04: Plugins and Themes
One of the biggest attack vectors is through 3rd party components of WordPress, namely the huge base of plugins and themes.
It is a good idea to have your plugins up to date, and you will hear that from everybody, as it is an universal answer to any problem. We understand, however, that the upgrade process can be hard and costly, especially if you used some version with a significant age difference from the currently developed one. Tools such as WPScan can help you identify known vulnerabilities, which should help you decide if that particular version upgrade makes sense.
By the way - there is a special rare case in which updating can induce problematic code into your site. It can be mitigated by using alerting tools to notify you of such an issue, but that does not mean it can be universally prevented.
There is one specific area which makes updates more difficult: using premium plugins. They are often not part of the official WordPress repository, so you have to visit the vendor site to get the latest version. Also, your subscription model could expire meaning you will need to pay to get those after several years have passed.
You can easily set a plugin to be auto-updated if it allows it (usually needs to be a part of WordPress official repository). This can be accomplished on the Plugins screen. A similar procedure applies to themes.
The themes are even more tricky.
You won’t usually be using the default theme repository to locate a theme, nor is it a guarantee of a good one. Commercial themes of some value usually reside in marketplaces such as Themeforest.
If you plan to modify the obtained theme and keep it updated at the same time, you need to learn the concept of child themes. And still, be aware to test a lot after any update.
Paid themes usually bundle a set of paid premium plugins - visual builders, sliders... This comes with a penalty, however, as these plugins are fixed to some specific version and without the theme provider updating them, you will be stuck with it. For some typical plugins bundled this way, such as Slider Revolution, this created a potential for some real damage. Also very troubling are older 3rd party visual content editors, as the shift to Gutenberg editor made a lot of them non-functional (essentially a reason why some sites don’t update WordPress core - they would just cease to be editable).
So we recommend sticking to some rules regarding plugins and themes:
- Always try to use plugins from the official WordPress repository. Make sure the plugin is relevant, up to date and with good reviews. If you get your plugin code from the outside, there is a potential for it being malicious.
- If you need a premium plugin, ideally use one bundled from WordPress repository, with license key added in upon registration.
- Always understand you need to have a way to update the premium plugin in the future if needed. Learn how the plugin vendor provides maintenance and support for your paid fee and factor that into the decision process.
- Avoid bloated themes with lots of premium plugins bundled in, it is not a good deal in the long run.
- Learn and employ the child theme method for customizing any theme.
- Update plugins and themes as much as possible, but be prepared to carefully test, if changes did not break anything. Having a simply accessible staging environment spawned from the currently running production site is a big help.
- If you build a website for a client, think about discussing with them future regular maintenance. WordPress sites are not launch & forget!
05: Login, Administration
Here are a few tips regarding one of the more sensitive areas - WordPress administration and logging into it.
Login URL rename - being able to access these paths:
/wp-login.php
/wp-adminmakes it very easy for intruders. So the first complication we can throw into their path is renaming the access URL to the login screen. We recommend using a plugin such as Siteguard (see chapter 07 - tools) to manage this for you.
Do not use admin username - what makes brute-force login attacks very effective is trying admin username with a set of common passwords.
Limit login attempt count - being able to limit further tries once a certain count of logins is attempted also helps against brute force attacks. This is also something Siteguard could help with.
Use two-factor authentication - the presence of a second authentication factor is a very robust form of protection. There are a number of plugins that can enable two-factor.
06: Important tweaks
You can continue securing by applying some follow-up tweaks. I tried to sort them by importance.
Disable xmlrpc.php - this is a backwards-compatibility interface that has no real reason to be turned on today, except if you want to be targeted by a lot of specifically aimed automated attacks. There is an extensive article about xmlrpc from Kinsta.
File permissions - setting proper file permissions to files and folders is a small change that can also help a lot. Interestingly, WordPress does not change permissions automatically, like Drupal or other CMS systems at least attempt to.
wp-config.php hardening - as this file contains essential keys and access details to the database, you will be pretty much screwed if somebody gains access to it. It is possible to move this file one level above document root, and WordPress will automatically import it if the server configuration allows it. This is not possible on most shared hosts, though.
Disable file editing in production - WordPress administration can be used to edit files directly via several places. Good idea is to forbid this in production environments. Adding a constant to wp-config.php disables it.
Database prefix change - By default, WordPress uses wp_ as a database table prefix, using some different one complicates matters for automated attack vectors and SQL injection attacks. This should be done when you install the site, doing it any time later could be tricky.
As you probably noticed, I have been referring a lot to this great page from the WordPress team: Hardening WordPress. I recommend anyone interested to study this in more detail.
07: Using tools
I will mention 3 security tools we’ve been using extensively.
First is the Siteguard plugin, which I referred to above. It is an absolute necessity for quite a number of easily accessible tweaks, mostly related to login and alerting.
Second is WPScan, which comes in the form of a CLI program as well as a WordPress plugin. The main advantage of WPScan is having a wide database of vulnerabilities for plugins and themes, which can give you a hint of how secure your website is.
You need to register an API key with WPScan, the free option is limited to 25 API requests for one day, which is about enough to test one average site regularly. It produces a comprehensible list of found vulnerabilities and recommendations, with the option to alert you if something is wrong.
Third is Wordfence, which mostly focuses on providing a firewall to shield you from malicious activity aimed towards your WordPress. It also offers scanning and vulnerability detection, but it does not seem as comprehensive as WPScan is. Third advantage is login-specific tweaks, including two-factor enabling. Wordfence is available as a plugin, with the ability to be controlled by a central administration.
08: DDoS protection
The most serious type of attack to be subjected to are DDoS attacks, when your web server is the target of a concerted effort of thousands of deliberately deceived clients at the same time, requesting resources.
While DDoS is not exclusive to WordPress, some of its vulnerabilities such as xmlrpc.php make the situation ideal for potential attacks.
If your site is under a DDoS, there is not much you can do at the site level to handle it. Most important here is the network capability, and that block of infrastructure resides above your web server. DDoS protection is hence usually delivered via hosting providers, or specific 3rd party DDoS protection systems such as Cloudflare.
The most prominent effect of a DDoS is the site being taken down until the situation is rectified. That is the main goal of DDoS: to deny your users/visitors from using the service.
09: Bedrock / Roots.io
We have already published an article on the topic of Bedrock in 2018. In short, it is a complete redesign of WordPress internals to adhere more to good PHP practices.
Security-wise, out of the box Bedrock contains two important improvements:
- Isolated web root to limit access to non-web files (among others solving the wp-config issue addressed above),
- Securing the passwords using a more advanced bcrypt algorithm (helps if your database dump is stolen, and complicates brute force attacks).
Because the file structure is changed quite a lot in Bedrock, this makes it harder for automated attack vectors to succeed.
So as long as security is concerned, especially for custom design themes which are created from scratch, Bedrock makes a lot of sense as a replacement for a default WordPress installation.
Conclusion
This blog post is far from being comprehensive. The main objective is to show you that you should be paying more attention to security in WordPress.
We have developers in our team with experience in dealing with hacked sites, to clean the site from infection and put up relevant protection. Contact us if you need a hand.
