WordPress security needs constant review
WordPress security is always high on our agenda as website professionals. It’s incredibly important to keep the security of our systems (and, more importantly, the data within them) under constant review.
So, what should we be looking at when we run a WordPress security audit? Are there things that are specific to WordPress websites? These form the vast majority of sites that we build here at Fellowship?
Let’s get the obvious ones out of the way first!
We’ve covered many aspects of website security in past Fellowship blog posts so we won’t dwell on some of these more straightforward items. If you’re running a WordPress security audit, you’ll definitely want to tick off these items:
- Update the WordPress core and any third-party themes and plugins that you have installed. If any of these plugins or the active theme are no longer under development you should look to replace their functionality with a different plugin or even some bespoke development.
- Ensure your site is running over HTTPS. This means having a TLS certificate installed on your site. These are free now from Let’s Encrypt so there really isn’t any reason not to have one installed.
- Remove any themes and plugins that your site is not using (IE deactivated themes and plugins)
- Ensure your site is hosted within a secure data centre. Under GDPR, and other privacy legislation, hosting companies are obliged to inform you of the measures they have in place to protect your data. If you can’t find the information on their website just ask them*
- Always use strong passwords, especially on the, hopefully limited number of, administrator accounts.
- Enable Two Factor Authentication where it’s supported.
A more in-depth security audit
With those oft-cited and regularly regurgitated security considerations out of the way, let’s take a look at your website’s WordPress security in a bit more depth.
Security at the DNS level
The internet is built around the Domain Name System (DNS).
This is used to translate an easy to remember domain name such as google.com into that website’s actual address, known as an IP address, on the internet. A request for any web page is routed through the DNS so that its content can be found and returned. As such, DNS gives us a great opportunity to secure requests being made to our websites. We can stop requests to our sites from bad actors* before they even get to our servers.
* We use the term ‘bad actor’ to describe any person or automated system that is attempting to gain access to our digital systems for nefarious reasons.
Use a DNS provider that includes security features
Although some DNS providers include security features, many don’t. We advocate using a DNS provider that includes security features such as Cloudflare, Amazon Cloudfront or Microsoft Azure. These premium DNS providers usually also include Content Delivery Networks to help with website speed and optimisations which can help your site to achieve a ‘Good’ Core Vitals score too.
Check your domain name hasn’t been blocklisted
I often liken the internet to the American Old West of the late 1800s. Although there are a few Sheriffs trying to uphold the law, there are many, many more outlaws out there! One of those Sheriffs, however, are the blocklisters; organisations that track domain names that appear to be suspicious or operated by bad actors, and add them to a global database. An internet ‘Naughty List’ if you will. Unfortunately though the blocklister’s scans can sometimes return a false negative and incorrectly classify a domain name as being dangerous. There are a lot of blocklists out there but, we generally check the following when auditing a website.
Running your domain name through these checkers is well worth your time as they all tend to communicate with one another. So, if one blocklister notices that your domain name is on another blocklist, they may well add you to theirs as well!
WordPress security at the web server level
Web traffic that has been successfully transferred through DNS will next arrive at the web server which gives us our second opportunity to apply security measures.
Ensure your server is up to date (any security patches applied)
Although many web hosts do this automatically it’s not always the case, so it’s definitely worth checking. Recent high profile security vulnerabilities such as the Log4Shell vulnerability were mitigated by regular server security patching.
Close off any unused ports
Ports are used on servers to direct incoming traffic to the most suitable service running on the server. Any traffic brought to the server via http is directed to port 80; the website serving system, any traffic for the database is directed to port 3306, email traffic might be directed to ports 25, 110 or 143 depending on its type. These ports give bad actors a variety of ways to try and break into a server. We can mitigate this though by closing off any ports that are not in use. Fellowship don’t offer email services so it makes sense for us to always close off the email service ports on our servers. You can check which ports are open (or closed) on your server using the https://portchecker.co/ website.
Rejecting older TLS versions
Transport Layer Security (TLS) is a security protocol used to establish encrypted connections between servers and internet clients such as your web browser. As encryption technologies have evolved so the TLS protocol has evolved too. Older versions of the protocol are no longer recommended, therefore support for them should be removed from your website’s server. The only reason that you wouldn’t want to do this is if a significant number of your website users are still using older browsers which don’t support the newer versions of the protocol.
Ensure a firewall is configured and running
The web server’s firewall is actually where most of these server level security settings are applied. The firewall can be configured to reject suspected bad actors and to only allow known good actors access to specific services. For example only allowing direct access to the server to authorised users on authorised IP addresses.
WordPress security at the application (website) level
The final point at which we can implement security measures is once traffic is actually ‘on’ our website.
Plugin-based websites like WordPress can add security measures at the application level using a plugin such as Wordfence or WP Defender. These plugins include their own firewall functionality that can reject access to the website from known bad actors, perform malware and security scans and alert site owners to incoming threats.
Although we’re not big advocates of third-party plugins for WordPress, Wordfence and Defender are definitely an exception to this rule!
We’d also recommend that site owners upgrade these plugins to their ‘Pro’ versions which, in our experience, include exceptional support and real-time updates to their threat databases.
Review website packages and dependencies
Websites often use software packages and dependencies to help power specific pieces of functionality. These packages and dependencies might not always be updated as part of a CMS core or plugin update. So, it’s really important to know what packages and dependencies are running as, just like with any digital system, this software can be vulnerable to attack. Any out of date software should be updated and anything that’s no longer being used should be removed.
A word (or two) on Security Headers
The internet is based around the concept of requests and responses; You make a request from a website and its server responds by showing you the web page you asked for. We can add extra instructions to these requests and responses using ‘headers‘. Specifically, how we want to handle certain requests and responses from a security point of view.
As the internet evolves, more and more of these headers are being introduced. While many are still experimental, or not yet supported by all browsers, they can add an extra level of security to your site.
To see which headers your site is (and isn’t) implementing you can use the scanning tool on the securityheaders.com website.
The good news is that these headers can be set at the DNS, web server or application level (or a mix of all three). As of May 2022, We’d suggest setting the following headers:
- Content-Security-Policy header
- Referrer-Policy header
- Permissions Policy header
- X-Frame Options header
- X-Content-Type-Options header
- HTTP Strict Transport Security (HSTS) header
Security should always be a high priority for website owners and operators and it should be kept under constant review as the internet (and the global landscape around it) continues to evolve. You may think that your site is unlikely to be a target for bad actors but, in reality, these actors are most often, automated and indiscriminate. Like search engines they simply follow links throughout the internet attempting to cause havoc wherever they go. The bad actors are often well funded and can even be state-sponsored.
Implementing the security measures described above will strengthen your website and its server enormously against cyber security threats both new and old.
More importantly, as website operators, we are inherently data controllers. We are legally obligated to secure our users’ data.
We are proactively suggesting a security audit, taking all of the above into consideration, to all of our clients.
Although we specialise in WordPress websites most of the security considerations discussed here are applicable to any website.