Here’s the slides from my talk on how to secure your WordPress website, which I gave at the WordCamp UK 2014 conference in Bournemouth on 12th July. I shared some security best practices and a few practical tips you can use to help harden your WordPress installation.
Note, this article is mostly aimed at advanced users!
About me:
Many of our clients at Primary Image are small and medium-sized businesses, but we’ve also worked with large organisations such as Transport for London and a couple of politicians too, so we have to take security seriously.
So why am I speaking on the topic of security? Not only do we design websites, but we also handle their hosting, WordPress updates, etc, so we’ve developed a checklist that gets put into place on all our client websites. There’s sometimes different security settings applied on a per-site basis too.
Why is WordPress vulnerable to attacks?
Attacks will often concentrate on the most used platforms and software, so that’s why Windows, Microsoft Office, etc, are targeted too.
It was late at night, about 1am, about four years ago and I was just about to go to bed. I received an automatic notification one of the websites had gone down. I took a look to investigate and saw…
It was a politically-motivated hack to draw attention to a topic. My latest backup of the site was about a fortnight previous and new blogs had been added in the meantime, so it took a lot of work getting the site restored from a clean backup and then recovering data from the hacked site. I eventually got the site fully back around 7am. I also investigated how the attack happened with the hosting technicians.
In fact a friend who hosted his websites also had one of his WordPress websites defaced just a few days later, this time by a different political group!
How often are there potential security vulnerabilities in WordPress?
A couple of months ago a security issue was found in the All in One SEO Pack plugin, which could have potentially allowed an attacker to conduct privilege escalation (i.e. a subscriber role could change a site’s SEO settings) and be vulnerable to a cross site scripting attack (XSS). These were fixed in version 2.1.6.
Also another recent headline, last month, reported a security flaw in TimThumb.
Back in April 2013, WordPress made mainstream news headlines when it was targeted in a massive botnet attack, which slowed (or even took down) several large data centres.
It’s important to know that most of these types of attack, whether defacing sites, denial of service attacks, etc, normally use automated bot programs. So anything you can do to change your website away from the default configuration makes it much more difficult for these automated attacks to be successful.
What happens when your WordPress website is attacked?
- The high number of requests to wp-login.php are no doubt brute force password attacks, where the bots try to use the login form and guess your username/password to access the Admin area.
- The “=register” one is where the bot is checking if user registration is enabled on the site.
- Requests to wp-comments-post.php will be a bot trying to post spam comments directly to the WordPress comment script.
- The /administrator/ URL is most likely a bot trying to find the login page for Joomla – another CMS platform.
- The really interesting one is the requests for GeoPlaces, which is a WordPress theme and I believe a security vulnerability was discovered in it, so bad bots are probing to see if you have this installed. 14,000 requests were made just for this on those 30,000 websites!
- The “author=1” URL can be used to discover the admin account’s WordPress login / username.
What does a botnet attack look like? Have a look at Securi’s video:
Whether your website is taken down by a denial of service attack or it’s defaced, it’s going to become inaccessible to your visitors/customers. It’s not only going to be embarrassing, but could hurt your SEO reputation, result in loss of sensitive customer data, you could lose customers, etc. So an attack can do real long-term damage.
At this point I asked the audience whether anyone had suffered from some sort of attack to one of their WordPress websites and it seemed around a third (perhaps more) had indeed experienced this.
Is WordPress secure and safe to use?
As shown in a previous slide, vulnerabilities can also be found in themes, and some of the attacks such as brute force password attempts can be targeted at other CMS platforms too.
Taking simple steps to secure your WordPress website:
See the WordPress Codex for some tips on hardening and protecting your website.
I certainly can’t cover everything here and this only covers a proportion of the things we do on our WordPress sites hosted by Primary Image, but I’ll share a few basic common-sense practical tips, as well as some more advanced techniques.
It was also not the only time security was being covered at WordCamp Bournemouth, which I think is a good thing as there’s so much to talk about and it’s an area that does need more awareness. Kieron also did a presentation and you can see his slides on SlideShare.
You wouldn’t, for instance, run a Windows computer on the internet without it having the security patches applied that are released at regular intervals, so don’t ignore WordPress updates either! Upgrades are now really easy and reliable – so you don’t have any excuses!
I came across a survey recently (produced earlier this year) that looked at 358 NHS websites using WordPress. Less than 50 were on the current version and five sites were using WordPress 2.9 or under (pretty ancient)!
Government websites can of course be more of a target for attacks. The team looking after the website in this example didn’t realise WordPress could be / needed to be updated.
Strong passwords can be enforced for other users with a plugin such as iThemes Security. Also be cautious of using public Wi-Fi!
I won’t mention the name, but one of our customers a while back had several websites with one of the “big name” hosting companies. They found they were getting hacked repeatedly and, after some investigation, the attacks were found to be coming in via the hosting environment as there were vulnerabilities in the server. So don’t let hosting be your weak link.
Ok it’s not really a security block, but nevertheless an important tip! Keep regular backups and don’t keep your backups within the same hosting account.
More powerful steps to secure your WordPress website:
Note iThemes Security used to be known as Better WP Security.
It’s interesting to see the log of failed login attempts – bots often try the “admin” username a lot.
BruteProtect uses a shared knowledge model to blacklist IP addresses.
However, I personally don’t rely on either of these plugins. There’s another method which doesn’t use a plugin that I’ll come onto shortly…
Sticking with iThemes Security, you can also use it for:
This is a step recommended by quite a few security guides, but I said that this method won’t hide your WordPress version number completely (there’s other ways of detecting your WordPress version, such as via the JavaScript files, etc).
On this slide, WordPress co-founder Mike Little said he doesn’t believe it’s worth doing, seeing as bots will attempt to exploit vulnerabilities in every website they find regardless of the version number. He argued that it’ll take up too much processing power for these bots to check the version number each time before probing for the exploit. I have to agree with Mike Little on this, so you might want to disregard this tip!
Changing the “wp” database table prefix eliminates predictable table names and could make it more difficult for tools looking for vulnerabilities to affect your website’s MySQL database if they’re targeting the default table names. You can use a plugin to do this, or do it manually.
- iThemes Security has a feature that can block IP addresses if they trigger too many 404 errors, which could be a sign of a denial of service attack. Personally I think this can slow things down even more and means your database can very quickly get filled up!
- There’s a feature to lock yourself out of your WordPress admin area for a period of time, such as if you’re going away on holiday. Why would you want to lock yourself out?! You never know when you might need to login again and personally I don’t use this.
- If you have a static IP address, then you could allow access to the WP-Admin area from just that IP address. But if you have an ISP that changes your IP address often, or you want to login to your website whilst on the move, then this isn’t ideal.
- I personally don’t like plugins changing my core files – I like to see what they’re doing and manually make changes!
- If you force members of the public to use a really strong password – they’re not likely to remember it! Use strong passwords for your admin / editor, etc, users.
- There’s a trend I’ve noticed recently where security plugins are giving you the option to block whole countries from accessing your website. It seems wholly unfair to me, and also geo-location using IP addresses isn’t always that accurate. Also botnets can come from anywhere in the world.
Several members of the audience were using Google Authenticator. It generates a one-time password and is available for your Android, iPhone and BlackBerry smartphone.
The .htaccess file – powerful security protection for your WordPress site
Next I delved more into the hosting account and went through some tricks you can do with the .htaccess file. You can do some pretty powerful things with it to secure your WordPress website.
The .htaccess file is simply a text file, which you can edit in a program such as Notepad. You’ll need a FTP program to edit/upload the file to your hosting account. When editing the file on your local computer, you may have to rename the filename to something else! They’ll be some WordPress rules already in the file, so don’t edit between where it says “Begin” and “End”.
# protect files <files wp-config.php> Order deny,allow Deny from all </files> <files readme.html> Order allow,deny Deny from all </files> <files license.txt> Order allow,deny Deny from all </files> <files install.php> Order allow,deny Deny from all </files> <files error_log> Order allow,deny Deny from all </files>
As the WordPress Codex says:
A second layer of protection can be added where scripts are generally not intended to be accessed by any user.
# Block the include-only files. <IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteRule ^wp-admin/includes/ - [F,L] RewriteRule !^wp-includes/ - [S=3] RewriteRule ^wp-includes/[^/]+.php$ - [F,L] RewriteRule ^wp-includes/js/tinymce/langs/.+.php - [F,L] RewriteRule ^wp-includes/theme-compat/ - [F,L] </IfModule>
You can build your own firewall by blocking suspicious URLs/requests. You’ll find various different examples by performing a search online. Most htaccess rules work fine with WordPress, but make sure you test your website afterwards!
Do have a look at the 5G 2013 list – it’s an excellent resource.
# STRONG HTACCESS PROTECTION <Files ~ "^.*.([Hh][Tt][Aa])"> order allow, deny deny from all satisfy all </Files>
What if we could put up a barrier before bots or attacks could even reach the WordPress login form or admin area files?
Note you can also do this manually, but I’ve shown the typical steps you can do through many web hosting control panels.
It’ll generate two files in your wp-admin folder:
Your control panel should have created a .htaccess file and .htpasswd file in your hosting account. Open up and edit the .htaccess file that was created in the wp-admin folder and add the following lines related to admin-ajax.php (you shouldn’t block this file), and optionally a custom 401 error page (displayed if users get the password wrong).
<Files admin-ajax.php> Order allow,deny Allow from all Satisfy any </Files>
ErrorDocument 401 /your-401-error-page.html
Next, open up your .htaccess file in the root of your WordPress installation (at the same level as the wp-login.php file) and underneath the WordPress rules already there, paste in these extra steps as shown below. It’s important the path to the .htpasswd file is the same as that used by the .htaccess file generated in the wp-admin directory.
Obviously change the example file paths shown here!
<Files wp-login.php>
AuthType Basic
AuthUserFile "/your-server-path/public_html/wp-admin//.htpasswd"
AuthGroupFile /dev/null
AuthName "YOUR USER MESSAGE"
Require valid-user
</Files>
ErrorDocument 401 /your-error-page.html
For those trying to login to your website, they’ll now see this extra security block:
The 401 error file should just be a simple HTML file and placed in the root of your public_html folder.
If you want, you can still use a login limits plugin too, but this .htaccess method will effectively block anything from getting to your login page if the user doesn’t enter the correct username/password at this first step.
<Files *.php> Deny from All </Files>
More advanced tips to protect your WordPress website:
; Disable allow_url_fopen in php.ini for security reasons allow_url_fopen = Off
; Disable allow_url_include in php.ini for security reasons allow_url_include = Off
; Disable display_errors in php.ini for security reasons display_errors = Off log_errors = On
There’s eight security keys used by WordPress. They’re used to create a cookie on your computer to keep you logged-in, etc. You can generate your own unique keys at: https://api.wordpress.org/secret-key/1.1/salt/
WordPress is usually pretty good at setting up the right file/folder permissions, but basically for folders you want writing allowed to the logged-in user only, then for things like robots.txt you’ll want this to be viewable but not editable. If you have a sitemap, you’ll want this writeable by the plugin you’re using.
These permissions may need to be slightly different for your exact server setup, for example wp-config.php should be 600 on some hosts, so check with an expert if you’re unsure!
And finally:
Don’t forget the basics, as no matter how many of the advanced steps you do, you need to get the simple steps in place too!
There are so many more tips and I obviously couldn’t cover everything in the presentation, but do your own research too and see what works best for your site.
If you’ve got any questions or other tips, do leave them in the comments box below!
Contact Primary Image if you need some advice on WordPress security, auditing of your current setup, or want help hardening your WordPress configuration.
Download a PDF version of the slides:
- Securing your WordPress Website – Presentation to WordCamp UK Bournemouth – July 2014 (PDF – 1.7 MB)
Slides also available on SlideShare:
Contact Primary Image if you’re interested in our WordPress services.

Mike founded Primary Image in 2010. He specialises in the WordPress website platform and speaks regularly at national web design conferences. Mike became a member (MCIPR) of the Chartered Institute of Public Relations in 2015.
Comments
Hi, this was a most eye-opening presentation.
I have a few questions:
1. Why do you not use 404 detection blocking in iThemes Security? And if you do, what can you do when you get an email saying a particular IP address has been locked out?
2. Can you use the functionality in iThemes Security to block PHP in the Uploads folder instead of adding an .htaccess file?
3. If you move wp-config.php up a level, is there any danger that WordPress won’t find it and your site won’t work?
4. Why those file permissions for robots.txt and sitemap.xml?
Hi Claire – glad you found the presentation useful. Good questions!
1) Personally I don’t use that 404 error detection feature, though I can see why it’s there and triggering lots of 404s could be a sign of a bot probing to find vulnerabilities, or a denial of service (DoS) attack. However, if the limits are set too low, it could easily block legitimate users (e.g. if you’ve redesigned your site and some URLs have changed, etc). I haven’t done any proper performance analysis of this specific feature, but I’d imagine it could be quite resource intensive, esp. as every time a 404 error is generated, it’s got to look up the IP address, check if it’s already listed, log down this new entry into the database records, etc. There’s other more effective ways of restricting what bots can probe for, and if it’s a DoS attack then they’ll be server-based systems that’ll be a lot better at handling this! It’s just a personal view and perhaps others do find this feature handy, but I’ve taken the choice not to enable it!
2) I haven’t actually tested this feature as I do it manually, but I imagine the plugin is doing exactly the same method! If you enable the option then check the /uploads/ folder, I guess it creates the .htaccess file for you?
3) Pretty much 99% it’s safe to do – I’ve never had an issue with this. In the unlikely event it did break the site (e.g. if you have an unusual hosting setup), simply move the file back! The WordPress Codex recommends this step, but there are arguments for and against the usefulness of this. There’s a long thread here! – http://wordpress.stackexchange.com/questions/58391/is-moving-wp-config-outside-the-web-root-really-beneficial
4) The robots.txt file needs to be viewable by everyone (i.e. for search engines), but just the owner needs write access. 644 CHMOD should also work ok and I’ve seen various suggestions on the internet for what to do with this file! The sitemap.xml file (if you have one) needs to be writable for plugins that update this file.
Hope that helps!
Mike