Last updated on 10 July 2020
RockmusicRaider proudly uses WordPress to deliver those snazzy music reviews to our fan base. First, because this is a rock-solid, well-known, and constantly updated system to build a site on. And second, because I consider WordPress to be pretty secure.
In fact, the success of a CMS (= Content Management System) defines itself around security-related considerations. It’s a bit like some real estate you wish to acquire. I am pretty sure that you would not buy a place that misses appropriate locks on its entries and sports holes instead of properly secured windows.
Methinks also that many other users reason along the same lines. WordPress‘ worldwide popularity speaks by itself. Some 34% of websites on the internet are powered by WP. On top, estimates say that roughly 60% of the CMS market share is usurped by this publishing software.
Security with WP is watertight, then. Right?
Usually, and generally speaking only, of course. Because nothing is ever fully locked down or will withstand the onslaught of state-owned agencies with bottomless funds.
Your site will always be under attack, and you are often at the whim of the firewall providers. But good sense and SEO demand that you always have at least one of those applications on your site. And this regardless of running a small local site or an international news outlet.
Also, you should always keep your logins and passwords at top levels. And this means:
- A user-ID that nobody can easily second-guess. In other words, never ever use the ubiquitous ‘admin’ as your ID. But use something else that is difficult to replicate. It is interesting how hacking algorithms always attack this one first. And its most obvious derivatives.
If you happen to use your email address for entry, do yourself a favor and use one that is not obvious. One that appears nowhere on your site, ever.
- Then, choose a password with real strength. And that means special characters and numbers inside of the garbled wording.
This will land you with a pretty solid first line of defense, a two-way authentication system if you will. Without even using your cell phone.
All of that should be pretty obvious, right?
And indeed more so, because many attacks center around guessing passwords – and user-IDs. On top of some pretty hefty exploitations through things like cross-scripts and – often – weak plugin code. Which is why you should always choose your plugins with a lot of care.
With all that you can minimize hacking troubles. But WordPress itself is not without its built-in flaws. Yet another unforced error-driven by defeatist beliefs.
Because your authors’ user-IDs show in the archive slugs!
Yep. You heard that right.
For any author active on your site, WordPress creates an author archive page. And this is – shockingly – identified like so: “example.com/author/user_login”.
Well, hell and damnation!
Your carefully coveted user IDs, the entry points into your system, all of a sudden appear on a slug. Openly displayed and visible to the public at large. And that is a major issue.
It is thus not the nickname that you so carefully chose, but it is the secret ID you use to log in that is on full display. In other words, you give 50% of your entry security away. By having WordPress show the wrong field in the author’s URL.
Frankly, it is beyond me that WordPress enables nicknames, displays them on the site, but sloppily shows the slug with the user ID.
It gets worse, though.
Popular SEO plugins like Yoast create sitemaps with these user IDs on full display. What a way to give them insidious hackers a neat little entry point. And a little hint to the brave. When I checked last, Yoast themselves do not show an author archive sitemap.
This is not to say that Yoast is at the source of the problem, and – in truth – they are not a firewall. For this, you have services like Sucuri or Wordfence. If anything, they should take that problem a tad more seriously until WordPress fixes it for good. Because – in the end – SEO is tightly linked to security. Ain’t it, Google?
So, if you use this plugin, here’s what we recommend:
- If you are a single-author blog, switch the author archive setting in Yoast to ‘Disabled’. Case closed.
This will not only reduce the possibility of duplicate content but also protect you from easy detection of your ID throughout this specific channel. You will thus not appear on any sitemap nor will you somehow end up in search results.
- If you run a multi-author blog, then set the author archives to ‘enabled’ AND hit ‘no’ below to avoid splashing your authors all over the search results.
Doing this will avoid your IDs showing up in a sitemap and search results. But – at the same time – your authors will have the honor of sporting a no-indexed archive page.
But that does not solve the problem of your user IDs showing up directly in the URL (yet).
So, what’s the solution?
There are several. And not all of them are really good.
I. Change the database.
The solution without a plugin will frighten some, as it requires some updating of a table on the backend. And you should indeed have a care. You’re operating straight in the bowels of your system, like one of them surgeons. And – usually – there’s no undo function.
Here’s how to go about it:
- Log in to your host.
- Fire up phpMyAdmin.
- Select the database for the site you want to update.
- Locate the ‘wp-users’ table. In case you changed ‘wp-‘ to something else, you’ll need to account for that.
- For the appropriate users, change the ‘user_nicename‘ field with the name you wish to use. Probably the nickname to be consistent.
This is the recommended solution.
II. Use a Plugin.
There are indeed several plugins that you can use. Here’s the link to Edit Author Slug. One of the better ones.
As always, yet another plugin will add to the load of your site and will – ultimately – have an effect on speed. Also, you are – as always – at the whim of the developers. Those who might or might not suddenly abandon your little helper program.
III. Change the code.
You can – of course – do that too. But this is a messy issue and I would not recommend it. Unless you have written the theme yourself, of course. And you know your way around child themes and such.
The final caveat.
First, I do not like those defeatist voices out there. Those that loudly proclaim an Act of God when it comes to fixing the problem with the author archives and their terrible URLs.
They simply throw their hands up in despair and state that there are multiple ways to detect a user-ID in the WP code. If you are so inclined, that is. And that is the reason why we all should continue to use ‘admin’ as our user login and stop worrying about it.
So, in their simplistic view, we should really all buy homes without locks and windows. Because – hey – a burglar will always get in. Which – again – is (kind of) true.
But we also know that strong defenses will force these same intruders to exponentially increase their efforts. Which – in turn – jacks up the entry cost and the final price to pay to levels many will think are not worth the sweat, nor the pain.
Amending the user IDs in author archive slugs is only one step to secure information vital to your installation. But one that you definitely should take.
Fixing all the other loopholes will take time, and you can only do that one step at a time. The best way to get this done is to work with the WordPress developer community to stopper them for good. That would be sustainable and – at the same time – will make WordPress greater still.