18 tips to secure your WordPress website: Part 3

Welcome to part 3 of our 18 tips that will help you make your WordPress installation more secure.  If you’ve not yet looked at parts 1 & 2, we’d recommend you start there, 18 tips to secure your WordPress website: Part 1 and 18 tips to secure your WordPress website: Part 2.

We’ve all seen the warnings in our browsers saying “Not secure” when we visit sites that aren’t using https and those warnings are only going to get bigger and scarier looking for your users.

Now we can (and should) tell WordPress that our WordPress Address and Site URL use https:

WordPress will now direct visitors who aren’t using https to the secure URL, but to do that WordPress still needs to start up, just to tell users to go to the address with https on it, and that’s a slow way of doing it.  A far better way of doing it, would be to add something like this to the top of our .htaccess file in the root of our website.

So what does this code do?  We’ll go through line by line and take a look:

1. Checks if the mod_rewrite module is available, if it is, carry on with the instructions inside the block
2. Enable the rewrite engine if it isn’t already
3. Check if the site is loaded without https (https = off)
   1. OR – Quite literally, “or the next rule matches”
4. Check if the domain is not kdaws.com e.g. kdaws.co.uk, www.kdaws.com etc.
   1. NC – Use case insensitive matching e.g. KDAWS.com is treated the same as kdaws.com
5. If #3 OR #4 match then redirect all requests from the original domain to https://kdaws.com/
   1. L – Last match, if this rule matches then send the response to the browser, don’t carry on with other mod_rewrite rules
   2. R=301 – Tell the browser this is a permanent redirect, not just temporary
6. Close the check for if mod_rewrite module is available.

In simple terms, unless someone visits our website as https://kdaws.com/ it will redirect them to there instead and will take maybe 10-20ms vs. potentially 500ms or much worse, we’ve seen it take 2s before now.

Just customise the code for your domain, just replace kdaws.com with your own domain as set in your WordPress settings – Don’t forget to put the dot as \. though on line 4.

Whilst you can move the wp-config.php file outside of your web accessible folder this can get messy and just isn’t practical if you’re running multiple websites on the same hosting package.  Instead you can take a couple of steps to protect yourself:

Not all providers have advanced filesystem protections in place, which means if your file permissions aren’t quite right then other users on the system can read your files, and in the case of your wp-config.php that means all of your database details and login security tokens.  This is where filesystem permissions come in to play, and we’re talking specifically about Linux here, as that’s where most WordPress sites will be running.

Depending on your providers exact configuration you may need to try two different values, we’re not going to delve too much in to how Linux filesystem permissions work, but for these purposes it’s a series of 3 numbers, from left to right the numbers mean:

1. Permissions for the files owner
2. Permissions for the files group
3. Permissions for everyone else (world)

Each of these numbers ranges from 0 to 7 and is made of of the permissions to:

1. Read a file (4)
2. Write to a file (2)
3. Run/execute a file (1)

The numbers in brackets are added together depending on the permissions e.g.

• Read only = 4
• Read and write = 6 (4+2)
• Read and execute = 5 (4+1)
• No permissions = 0

Your wp-config.php probably has permissions of 644 or 640 right now, meaning that:

• Your username can read and write to the file
• Your user group can read the file
• Everyone else can read the file (644) or no one else can read it (640)

Ideally we want to set 440 or 400 so that only your user and group (or just user) can read the file, as your PHP code should run as your username this means the web server will be able to read the file and run the code but no one else will be able to read it.  Which of the two you set depends on how your provider has their server configured, so you may need to try 440 if 400 doesn’t work.

The other important point is that your PHP code won’t be able to write to wp-config.php – meaning any malicious code won’t be able to change things in there.  This does mean if you need to make any changes though, that you will need to set the permissions back to 644 or 640 to edit it.

How you set these permissions really depends on your provider, if you have SSH access then you can set them with chmod e.g. chmod 440 wp-config.php, if you have access to cPanel or Plesk then their respective file managers both allow you to change file permissions.

Imagine a situation where for some reason (it can happen) your web server stops processing your .php files as PHP and just sends the content of the file to the user like a normal web page, now anyone who accesses your wp-config.php can see your database connection details, and the security tokens used to protect your user logins.   That would be very bad, so we want to stop that from happening.

We’re back with that .htaccess file again, this time we want to add:

This will deny access to anyone trying to access wp-config.php via the web server, but will still allow your site to work.  So no matter if PHP stops working or not, no one can access the file.

XML-RPC is WordPress’s remote API used by some plugins and mobile apps etc. so you may not be able to disable it depending on the plugins you’re using, but if you can disable it then we’d recommend it.  There are a couple of ways to do this.

If you want easy, granular control over what happens with XML-RPC then we’d recommend the Disable XML-RPC-API plugin as it allows you to completely block, just block selected methods, add IPs to allow and block lists plus some other security tweaks.

Once again, we’re back to our trusty .htaccess file, and this will look familiar by now:

We’re blocking all users from accessing the xmlrpc.php file, except the IP address 192.0.2.1 in this example – you can of course delete this line or adjust with a specific IP address you need to access the XML-RPC functionality.

We aren’t going to do a deep dive on to this here, as it’s worth an article all of its own (it’s coming), but we’d recommend looking at SecurityHeaders.io and scanning your site. It’s a great free tool from Scott Helme, a well respected security researcher and trainer. As a minimum we’d recommend setting the following security headers:

• X-Frame-Options
• X-XSS-Protection
• Strict-Transport-Security
• Referrer-Policy
• X-Content-Type-Options

You can of course set them from our ever faithful .htaccess file again:

Please be careful when making such changes, and read the information provided on the Security Headers website before implementing any of them.  We always recommend testing on your development/staging environment first.

This one might seem obvious to most people, but we still see on a weekly basis people asking on groups where they can get X, Y or Z plugin or theme for free instead of having to pay for it.  Aside from the issues of not paying someone for their work, who knows what else has been added in to the plugin or theme by the “bad actors” stealing it and giving it away?

Plugins and themes are PHP code, that means once they are loaded in to your site (even if you didn’t activate them) they are a security risk and can run any PHP code they like and have access to your databases and other files.

We’ve been a bit cheeky combining these two, but unless you’re running your own server then these two are really down to your web host if you want the best protection.

A Web Application Firewall (WAF) checks requests coming in to your site for common attack patterns such as SQL injection, Cross Site Scripting (XSS) etc. as well as some application specific checks e.g. a known flaw in a WordPress plugin and stops the attackers in their tracks.  Often this is combined with the servers firewall to block attackers from accessing the server once and attempted attack is detected.

Malware detection comes in many forms:

• Weekly scans
• Daily scans
• Scan files on access
• Realtime protection

With weekly or daily scans there is the chance that malware could be uploaded and not found for a period of time, during that time it could be running who knows what, and accessing your data and sending it all over, or trying to infect your users.

Scanning files as they are accessed is a step up, and can prevent malware from executing as it scans the file when the code is read, and if it matches a known pattern then it will be blocked, but this still isn’t perfect either as it relies on the malware following a pattern that the system already knows about.

Realtime protection is another step up, as it analyses the actual code being run, and decided if it looks like something malware would be doing and if it is it will block the request.  This makes it harder for malware to hide itself.

In an ideal world we want a combination of techniques to make sure we aren’t missing anything.

We hope you’ve found this series useful, even if you’ve only taken one thing away from it we will have done our bit to help protect the web that little bit more.

If you think we’ve missed anything then please let us know via our social media channels.