WordPress has grown to become the most popular web publishing platform in the world. With modern hosting environments providing one-click WordPress installations, today you can be up and running with a WordPress site in a matter of seconds.
There’s just one small problem. WordPress websites are notoriously insecure. Often this isn’t even because the WordPress code is vulnerable, but because the site or hosting environment were not set up and configured correctly.
Since there’s so much misinformation on the internet around this topic – I decided that I’d create my own guide to hardening your WordPress website.
1. Update WordPress (Let’s go back to basics)
The simplest advice is often the most effective. Human beings aren’t perfect and neither are software platforms. Developers make mistakes, bugs are introduced with new features and security researchers discover vulnerabilities.
While WordPress has a reputation for solid code – we can never account for the unknown unknowns. These are vulnerabilities that might exist within WordPress which have not currently been discovered or disclosed.
We should always ensure that WordPress is maintained and kept up to date. Fortunately, this is a fairly simple process. Since version 3.7, WordPress has featured automatic updates.
For those that want to update manually – just click on the updates icon to the right of your site name. This will provide you with a list of all of the pending updates – so that you can help to keep your site secure.
2. Use Reputable Plugins
The single biggest source of WordPress hacks are out of date or poorly coded plugins. WordPress is an open-source web publishing platform that permits anybody to build and publish their own WordPress integrations.
This is great because it allows the WordPress community to expand the features and functionality of WordPress, but it does come at a price. Many plugins are riddled with security flaws and can be produced by anybody with a moderate ability to code some PHP.
This independent code is often poorly developed and maintained – particularly from a security point of view. It’s critical that you limit the number of plugins that you use on your site in order to reduce your attack surface.
When you do use plugins you should only use those that are widely-used and reputable – such as those listed on WordPress.org. While these plugins themselves can never be entirely secure either, they’re more well established and reputable than obscure third party plugins.
They’re also the plugins that are most likely to be regularly updated and maintained – which is essential for patching new security issues.
Here are some sources of legitimate plugins and themes that I trust: –
- For 99% of plugins you only need the official WordPress plugin repository.
- CodeCanyon.net is an excellent source for commercial WordPress plugins.
- The official WordPress theme directory contains many great (and free) themes.
- Themeforest.net is a reputable source for commercial themes.
- ElegantThemes is a reputable site. I used their plugins on this blog
- Themify.me has many commercial responsive themes.
Again the process for updating these plugins is fairly simple, just hit the update icon to the right of your site name. You’ll be able to perform all of your updates in once clean sweep just by clicking select all and then update.
(Protip: Disable any plugins which you do not use! Disabling them alone is not sufficient to prevent any security issues from being exploited!)
3. User Accounts
WordPress allows for multiple user accounts – where each account is assigned an individual role. These roles are: –
These roles allow you to host guest bloggers, or even have somebody else log into your site and edit your posts. Of course, each of these roles has varying levels of permissions within the WordPress admin panel, with the Administrator role having the highest.
It’s important that you restrict the number users with an administrative account to the absolute minimum possible. In cases where you must provide somebody with admin access, for example a developer, then you should always provide them with their own unique account.
This helps you to audit the changes that they have made, which can be useful for change control , but also from a security logging point of view. You should ensure that these user accounts are also removed once they are no longer required.
(Protip: If you really want to throw the cyber criminals off the scent then rename your default admin account from ‘admin’ to something else entirely)
Message to the WordPress Gods: Please introduce auto-expiring accounts.
4. Enable Two-factor Authentication
So what’s even better than restricting administrative access? Having a single admin account and then enabling two-factor authentication on it. While this feature isn’t natively built into WordPress, you can use a plugin called Clef to add this additional functionality.
With Clef each time you log in you must also use your mobile phone to scan a digital code. This extra layer of security is great for preventing unauthorised access to your admin accounts – and can prevent basic password guessing and brute force attacks.
5. Use Strong Passwords (Strength in length)
Using two-factor authentication is not an excuse for failing to follow Rule #5. When creating passwords I highly recommend that you allow WordPress to generate them for you using the Show Password button. WordPress will automatically generate an alpha-numeric, upper and lower password with sufficient length and punctuation.
If you’re adamant that you’d like to go ahead and use your own password then common sense rules apply. Choose a password that’s unique to that site which you don’t use anywhere else. Ensure it’s a minimum of 12 characters in length, and use upper and lower cases letters, numbers and special characters.
While most WordPress exploits will come from vulnerable themes and plugins – you may also want to install a plugin to help you handle brute force attempts. Brute Force Login Protection will allow you to limit the number of login attempts, auto-block malicious IPs and much more.
You can download it here: –
When combined with two-factor authentication and a great password your admin account should be in pretty good shape. Let’s move on ..
6. Learn to Love HTTPS
We’ve moving towards a secure world – a world where TLS certificates can now be obtained completely free of charge (for more information on this see Let’s Encrypt’s website https://letsencrypt.org/).
Switching your website from HTTP over to HTTPS will protect your visitors. While you may not be handling sensitive information (e.g. payment data) it’s important that your visitors feel like their browsing session is completely secure. It improves trust and increases conversions.
Enabling HTTPS isn’t only a best practice but it’s going to be a requirement if you want your site to remain in good standing amongst the major web browser vendors. Google have recently announced that as of 2017 Chrome will flag some non-HTTPS websites as ‘Not Secure’.
Proceed in plain-text at your peril ..
7. Learn to Fear FTP
Most WordPress sites are administered using something called FTP, which stands for <Insert any word beginning with F> Terrible Protocol. Okay I’m kidding – it stands for File Transfer Protocol. The file transfer protocol has been around for a long time now and is primarily used to transfer digital files from one location to another.
Since FTP has been around for a long time, it was built before security and privacy had become a real issue on the internet. This means that FTP uses no form of encryption when sending and receiving data over the web.
While this can be a problem for sending and receiving files – it’s a particular issue for the authentication mechanism, which also occurs in plain-text. This means that an attacker also sitting on your network can use their computer to ‘sniff’ your FTP login credentials over the wire (or the wireless, if that’s even grammatically correct).
The solution to this problem is to ensure that you’re always using an encrypted file transfer protocol to connect to and manage your sites. Some alternatives include sFTP which is like FTP over SSH and FTPS which uses Transport Layer Security (TLS) in order to secure your data.
8. Get a Plan B
Plan B is Plan Backup. This is the holy grail. It’s the B in the ABC of security. In fact, I made that up. There is no such thing. If you’d like to make it a thing then please email me your suggestions using the Contact Page. Moving on, backups are critically important – they’re actually like your worst case scenario insurance policy.
We don’t want things to ever go wrong, but unfortunately they often do. You should never rely upon your hosting provider to take these backups for you, as other people have unfortunately learned in the past (click here to read about how Crazy Domains lost all their customer’s hosting data).
Make sure that you always take backups of both your files and your database. With most providers you’ll be able to do this from your web management console – e.g. cPanel. If you’re unsure on how to do this then please contact your hosting provider.
You should ideally be taking site backups at a minimum of once a week – depending upon how much your site changes and how often you’re publishing new content. Most hosting companies will provide you with the functionality to do this automatically on a schedule – which I’d highly recommend looking into.
(Protip: Ensure that these backups are not accessible remotely. Do not store backups inside your web root!)
9. Shared Hosting (Sharing is not always caring)
Shared hosting can be a great cost-effective option for many small businesses that want to get themselves an online presence. For larger businesses, or those with a more significant online presence (e.g. e-commerce) then it might be worth looking into a dedicated hosting solution.
The issue with shared hosting from a security point of view is that the server you’re hosting on is being shared with other people. There’s often a very fine line of separation between your website and the websites of other customers.
Shared hosting environments can run potentially hundreds of websites on a single server – which means that there’s several hundred additional points of compromise which you cannot control. If any one of those websites becomes breached, then the attackers might be able to gain control the entire server.
To avoid this problem you should go with a reputable hosting provider than has properly configured and secured their shared hosting platforms. This is a great way to minimise any risk.
It may even make sense to host your site on your own dedicated server. This doesn’t only have several security benefits, but also provides you with your own dedicated resources, which can be great if you want more control over your website or experience higher volumes of traffic.
10. File Permissions
So we’re about to dive right in now and get a little more technical. If you’re non-technical don’t worry – I’ll do my best to break things down into a language that’s a little more familiar (I find English generally helps). So, on every web server there are three primary permissions: –
R – Read (View the file)
W – Write (Change the file)
X – Execute (Run the file, like a program)
These permissions are shortened to R,W & X. Every file and directory on your web server will have one of these three permissions. Are you with me so far? Great!
Now on every web server there are also multiple users and groups. Each user or group is assigned a unique set of permissions for each file or directory. For example, the default user account for Apache web server inside a Linux environment is www-data. A group is just a collection or logical grouping of these user accounts.
Let’s take the robots.txt file we discussed earlier on. Since we want web crawlers to be able to visit our site and read that file we’ll want to make sure that it’s what we call world-readable. That is, the file should be accessible and readable by everyone.
Funnily enough, inside Linux (the most popular operating system for web hosting) there’s a group designed just for that purpose. It’s called the everyone group. By allowing the everyone group to read the robots.txt file we make it possible for anybody to browse to www.domain.com/robots.txt and read the contents of that file. Perfect!
Now we wouldn’t want people to be able to change our robots.txt file – because they could maliciously alter it to make sure that the search engines don’t index our site at all. In order to prevent this, we just have to make sure that we don’t also give the everyone group the write permission.
In fact, this isn’t the only file that shouldn’t be given write permissions. There are many files and directories within WordPress that should not be publicly readable or writable – for example the WordPress configuration file (wp-config.php) which contains your database credentials.
Many of these files are protected by default, but some may take some additional configuration, depending upon the setup of your hosting environment.
Some of these are: –
/wp-admin/ The WordPress administration area: all files should be writable only by your user account.
/wp-includes/ The bulk of WordPress application logic: all files should be writable only by your user account.
/wp-content/ User-supplied content: intended to be writable by your user account and the web server process.
A full explanation on how to lock these down is beyond the scope of this article, so I recommend that you take a look at the following documentation from WordPress.
11. WordPress Configuration File
We mentioned the wp-config.php file earlier which contains your highly sensitive database credentials. This is the last file that you want falling into the hands of the attackers and so it might make sense to store it outside of your web root directory.
A typical web root will look something like /var/www/html and leaving your WordPress configuration file here might present a security risk. In order to mitigate against this risk, you may want to migrate the file to a non-public directory where it will be more secure.
For a full-guide on how to do this please see the following article from Jack Busch at Groovy Post: –
12. Install WordFence
Finally – I’ve saved the best until last. WordFence is a WordPress security plugin which implements many of these security best practices for you. WordFence is like a one-stop security shop and will protect your website against both hacks and malware infections. Here’s just a small selection of WordFence features: –
- Web Application Firewall
- Real-Time Threat Defence Feed
- Block Brute Force Attacks
- Country Blocking
- Malware Scanner
- Intrusion Detection System
Fortunately, WordFence offer both a free and a premium version of their plugin which can be downloaded using the following link: –
Let’s bust some common myths about securing the WordPress platform. First up ..
Don’t Password Protect /wp-admin/
One of the common mistakes I see is WordPress administrators who try to protect their administrative area by password protecting the /wp-admin/ directory. Specifically, administrators will place a .htaccess file in the /wp-admin/ directory that cause the web server to prompt anyone trying to access that directory with a “basic authentication prompt”.
A basic authentication prompt is a simple form of authentication that causes the browser to pop-up a dialog asking for a username and password. It is very easy to implement by adding a few lines to a .htaccess file.
The problem with password protecting your /wp-admin/ directory is that your regular site visitors need to be able to access that directory too. The AJAX handler for WordPress lives in that directory at /wp-admin/admin-ajax.php. While this may look like something that is only accessed by admins, it is badly named and is accessed by any feature in WordPress that requires AJAX functionality.
If you password protect /wp-admin/ you will break functionality on your site and your normal site visitors may see the basic authentication dialog popping up in their browsers. Don’t do it.
Don’t Change your Database Table Prefix
There is an urban legend that by changing your database table prefix you will prevent certain kinds of attacks. This is completely incorrect.
There is a command available in MySQL called “show tables;” which shows all tables. Any bot or human hacker will call ‘show tables’ before trying to access your database tables and will immediately see what your database table prefix is and use that when referencing your tables in an attack.
The default table prefix in WordPress is ‘wp_’. Most hosting providers change this to something else when your site is configured. So it is likely that your table prefix has already been changed and installing a plugin or script that changes your table prefix again is pointless and an unnecessary risk to your database tables.
I hope you’ve enjoyed this article on How to Secure Your WordPress Site Against Hackers. In this article we’ve covered the essential steps that you need to take in order to secure your WordPress site. In my next article I’ll be covering the essential steps that you can take in order to secure your hosting environment.
Like this post?
Share it with your network!
What are YOUR experiences with WordPress?
I’d love to hear YOUR comments!