Why I’m Blaming WordPress For Its Own Security Flaws

Last year I wrote about a website got hacked and received a severe Google penalty. This really put website security on my radar, and I wrote a follow-up about performing basic site security scans to thwart most automated hacking scripts.

Since then I’ve developed my web security offering and am helping more and more clients with implementing basic security measures for their websites. Many sites I work with are built in WordPress, and over the past months I’ve come to realise that most of the security flaws inherent in that system can be quite easily addressed.

In fact, it’s so easy to prevent the vast majority of WordPress hacks, that I’m baffled that these preventative measures aren’t implemented by default.

It’s as if the lead developers in charge of the WordPress.org platform don’t care enough about security to put some basic roadblocks in place that will defuse most automated reconnaissance scripts and make hacking WordPress sites more time-consuming.

Here are some of the very simple and straightforward measures that WordPress.org should implement to make sites safer:

1. Admin Username

For starters, the ‘admin’ username should be banned. At no time should WordPress logins use any kind of standard username. Right now, the default username for the administrator account of a new WordPress installation is ‘admin’. Many website owners never change that username. This allows brute force attackers to simply focus on the ‘admin’ username and then try all kinds of different passwords.

But if the ‘admin’ username doesn’t exist, it makes brute force attacks much harder.

It would be a very straightforward fix to simply reject ‘admin’ as a legitimate username, and force new installations to choose a different username for their primary administrator account. By doing that, WordPress can significantly raise the difficulty for brute force attackers.

WordPress login

2. /wp-admin Login Folder

The /wp-admin folder is where WordPress account holders log in to their website’s back-end. Because this is a standard folder for all WordPress installations, hackers know exactly which folder they need to look at to gain access to a site.

It’s not complicated to protect a website’s admin login folder. WordPress should take measures to protect login folders by randomising them and/or allowing website owners to very easily change the name of their login folder.

Right now, we have to rely on plugins to do that, and often those plugins can create conflicts with other plugins that require /wp-admin folder access. It should be a key priority for WordPress to protect the admin login folder and change the way plugins and other systems access this folder.

Also, the location of the /wp-admin folder is being broadcast in the site’s robots.txt file. The /wp-admin folder is included in a WordPress site’s robots.txt disallow rules to prevent search engines from crawling it and potentially showing these login pages in search results.

WordPress robots.txt

Yet this is a terribly ineffective way to protect a login folder.

First, a robots.txt disallow rule doesn’t actually prevent a search engine from indexing a folder. If there is a publicly accessible link to a page in a disallowed folder, search engines can still index it – just not crawl the link’s target.

Second, every website’s robots.txt file is publicly viewable. Anyone can look at a website’s robots.txt file. So by including your website’s login folder in your robots.txt disallow rules, you are basically broadcasting that folder’s location to anyone and everyone.

A much more effective way to protect your login folders is to implement the meta robots noindex tag on all pages in those folders. This genuinely prevents these pages from being indexed by search engines, and you don’t need to publicly announce where your login folders are on your website.

3. Version Numbers

Lastly, every WordPress installation announces its version number straight in the source code:

WordPress version numbers

I’m fine with websites having a meta generator tag for CMS creators to claim some form of credit. But putting a version number in there is totally unnecessary, and presents a huge security risk.

For an open source platform like WordPress, publishing a version number is like laying out a red carpet for hackers. Because of the open source nature of the platform, hackers know exactly which security issues have been fixed in each version of the system.

So by announcing the version number in the source code, a WordPress website is basically telling hackers exactly which security exploits have been fixed – and which are still unpatched.

For websites that, for whatever reason, aren’t up to date with the latest WordPress fixes, the inclusion of the WordPress version number in the source code presents a severe security risk. It tells potential attackers exactly which known exploits they could use to gain access to the site.

It’s a ridiculously simple fix to omit CMS version numbers from the source code. Without version numbers to work with, hackers will have to perform much more manual scanning to try and find exploitable issues on a site. And increased effort for hackers means fewer hacked websites.

Easy Fixes

While by all accounts the people behind WordPress are working hard to make their platform more secure, some of the most obvious security flaws remain unaddressed. For me, this is almost unforgivable.

Basic security measures should not be optional extras in any CMS, especially one as popular as WordPress. By introducing some basic measures to enable secure usernames, cloaking login folders, and not publishing version numbers, a WordPress installation can discourage most automated hacking systems and prevent a huge amount of hacking attempts from succeeding.

I genuinely don’t understand why such measures – which have been suggested to WordPress many times – have not yet been implemented.

Until then, WordPress websites will continue to be hacked and compromised with ridiculous ease, and people like me will continue to spend significant time and effort to clean up the mess.

Update 02 March: some have commented that these security flaws only prevent brute force attacks, and these are a minimal risk. Yet Wordfence reports that in January they saw over 26 million brute force attacks every day – and that’s only on WordPress sites that have the Wordfence plugin installed.

Brute force attacks are a serious security risk, yet WordPress is ill-equipped to deal with them out of the box.

Opt In Image
Know about what is changing in marketing!

Keep up with the latest digital marketing developments, views and how-tos through State of Digital’s digest newsletters. Be the first to hear about events, white papers, e-books, webinars, training and more!

You will receive the free e-book "Content Marketing Essentials" as a thank you!

* Personalize your experience when signed up!

About Barry Adams

Barry Adams is one of the chief editors of State of Digital and is an award-winning SEO consultant delivering specialised SEO services to clients worldwide.

  • Jem

    The problem is, relying on security by obscurity – which is what your proposed solutions are – makes people complacent. Complacent people don’t take real, necessary precautions to keep themselves safe. None of these suggestions address real issues with out of date installs / plugins, or indeed in people blindly adding dodgy themes and code to their sites which (in my experience) are the biggest cause of compromised WordPress installs.

    I have managed hundreds and hundreds of WordPress websites over the past 10 years and none of them have ever been compromised because of their username, admin folder location or the version meta.

    • Maybe I’ve just been unlucky then Jem, as I was involved with the cleanup of two websites that were hacked by brute force-ing the ‘admin’ username in a standard /wp-admin login. It may not prevent dedicated hackers but it heightens the barrier to entry for script kiddies – and that’s not a bad thing in my book.

      And how would you know the version number hasn’t been reviewed to decide on what exploits to use? If a website was hacked, it means an exploit was used to gain entry, and that means there was some unpatched code on the site somewhere.

      Do you agree that broadcasting version numbers is pretty silly and serves no purpose, yet presents a significant security risk for a platform as widely used and easily compromised as WordPress?

      • Jem

        I agree, broadcasting the version number serves absolutely no purpose whatsoever – and I don’t personally create admin accounts with a username of ‘admin’ either – but the vast majority of compromised installs are not script kiddies on a “one on one” mission or caused by people who target specific version numbers. They (e.g. this 4.7 / 4.7.1 issue from this week) are usually executed en masse to lists of known WP installs, version be damned. See http://thehackpost.com/wordpress-rest-api-exploit.html for an example proof of concept. The only time the version is known/assumed is when the exploit fails.

        So while I agree with some of the points you’re making about the ease of fixing these ‘issues’, my concern is that a) they’re largely redundant, as anyone who knows WordPress can easily figure out usernames and version numbers anyway and b) that by discussing these issues we’re not discussing real weaknesses in the system (which 9 times out of 10 is the user… but unfortunately most sites require users ;))

        I disagree that WordPress is ‘easily compromised’, though. They have one of the most proactive, reactive security teams of any open source (and indeed closed source) project I have ever seen.

        • I will defer to your superior knowledge on these matters – I am after all just an amateur dev. 🙂 I just find it somewhat incomprehensible that these very basic stumbling blocks haven’t been introduced. If it makes WordPress just 5% safer – as I am sure it does – then it’ll be worth it.

      • Jem

        Just for the record, I have only had two installs of WordPress compromised in the entire time I’ve been using it (a very long time).

        One was caused by a plugin which relied on timthumb (so the version of WordPress, and thus the meta tag, were irrelevant) and the other was a WP install that had been uploaded but not installed; the install was completed by someone else using 3rd party external MySQL details (my own stupidity/laziness the cause).

  • Good tips, Barry. Knew about most of these but not all of them.

    An interesting one I was told the other day: add “/readme.html” to the end of the root domain and you’ll see a site’s version number (e.g. http://seono.co.uk/readme.html ). I’m in the process of changing/removing them from the sites I manage, even though I keep mine mostly up-to-date, but for a site that rarely updates, it could be a big red flag to would-be hackers…

  • Ben Matthews

    A great plugin to remedy this is Sucuri which will go through a process of hardening these suggestions (with the exception of changing the wp-admin) URL. Shield by iControlWP (a Belfast based business) is also a good option.

    I’ve encountered many WordPress sites that aren’t secure and are vulnerable to brute force or dictionary attacks on the login. Some hosts do ban ip addresses after several unsuccessful login attempts (A2 hosting do this), but many do not. Additionally using a service like cloudflare can help filter away known “hacker” traffic using a web based firewall.

    Incidentally, I’m giving a talk about this issue as I am using our company login process as a case study of project management, development testing and user experience at the WordPress NI evening at Farset labs (see Meetup for details). I’ll be showing how I created a simple plugin to implement Google recapture on the login page to prevent bot login attempts.

    Funny how you posted about it the night before.

    • Thanks for this Ben, I hadn’t heard about WordPress NI.

  • Jonathan Hochman

    Most WordPress hacks are NOT by brute forcing the login. Most hacks occur because WordPress core, themes or plugins haven’t been patched. WordPress can be secured very well with two easy steps. (1) Set up automatic daily backups with CodeGuard or WP Engine. (2) Set up automatic daily patching with a plugin like Advanced Automatic Updates. Do those two things and your chance of being hacked drops to near zero.

    For extra protection get CloudFlare. This will block most automated hacking attempts before they even access your site.

  • I agree with you Barry, WordPress should make this easier by default and for novice users. I use the ‘All In One WordPress Security and Firewall Plugin’ on my sites now but even that is not as straightforward as I’d like. I appreciate that security shouldn’t necessarily be easy, but if we all want to be better at security, then surely it does need to be easy!

  • On the topic of brute force attacks, Wordfence reportedly blocks 25 million brute force attempts each day. I’d say that makes it an issue for WordPress to deal with, as per my article.

    https://www.wordfence.com/blog/2017/02/january-2017-wordpress-attack-activity-report/

  • On the topic of brute force attacks, Wordfence reportedly blocks 25 million brute force attempts each day. I’d say that makes it an issue for WordPress to deal with, as per my article.

    https://www.wordfence.com/blog/2017/02/january-2017-wordpress-attack-activity-report/

  • I would also recommend using vulnerability scanners like WPScans.com or the open-source version at wpscan.org