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.
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.
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:
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.
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.