Security Through Obscurity is Not Security At All

A broken bike lock – a symbol of security through obscurity

What counts as security, and how you make sure that you’re secure are both big and complicated topics. But, the complication of them is worsened when people mistake useless task-creation for actual benefit. “Security theater” has been an ever more common term used to characterize practices that look like they improve security but don’t really do much of anything at all.

There’s a specific class of common WordPress security advice that just isn’t really worth all the time and energy that people spend on it: hiding the fact that you’re running WordPress. I think that while some of the often-recommended “security through obscurity” features have value for an average WordPress site, they aren’t worth the hassle.

In this article, we’ll start with a brief overview of how to think about security with WordPress, cover what “security through obscurity” is, which practice it entails, and then what modest benefit it does have.

Oh, and if you want some guidance on some actually helpful WordPress security advice, you should sign up for my free course below. It’s a brief, valuable, and fun mini-series which gives you a preview of WordPress Security With Confidence, my new course.

WordPress Is Secure, Anything Else is FUD

Basic WordPress is secure. WordPress running plugins and themes is still secure.

FUD is a common acronym inside of the tech community. It stands for “fear, uncertainty, and doubt.” When you say that someone is spreading “FUD”, you generally mean that they’re using uncertainty or doubt about the usefulness of a given technology or idea to spread fear of it.

It is very common for people who know very little about WordPress to say that it’s insecure. And there’s some reasons from history that this diffuse thought should be honored as holding some truth. But most of the things that have historically made “WordPress” insecure aren’t WordPress, the core software. They’re old websites maintained poorly and with software installed by people not realizing the seriousness of what they’re doing.

The core of WordPress is as secure as any similar tool with its history and vintage could be. Most of the security issues that are found and fixed in it today are pretty obscure and esoteric. They’re not things that are easily exploited on a random sites by a malicious attacker. So if you let WordPress auto-update as it should, you never really have to worry about WordPress itself being insecure.

That said, the ecosystem that surrounds WordPress is vast. And while eyes on security in the core tool have made it rather hardened, the broader ecosystem still contains lots of themes and plugins that make security blunders from time to time. This is natural and understandable, but those vulnerabilities are sometimes big and important to watch for. But most aren’t. And even those can largely be protected against if you simply keep your plugins and themes up-to-date. Basic WordPress is secure. WordPress running plugins and themes is still secure. But that doesn’t mean you shouldn’t take some further steps to make your site safer.

What’s Security Through Obscurity

Security through obscurity is the reason that you don’t leave you valuables visible in your car in a well-populated area.

Security through obscurity is a general practice through many parts of the world. An example: security through obscurity is the reason that you don’t leave you valuables visible in your car in a well-populated area. By obscuring your valuables with a trunk or blanket, you make it less obvious to a potential attacker what benefit they may get from breaking into your car.

But with technology, security through obscurity is often a bit different. Specifically here, we mean security through obscurity when you rely on people not understanding how your site is built and where they can expect to find its files to protect you.

Another common security by obscurity technique is to “secure” certain files they don’t want seen by labeling them as “School Work” or something similarly innocuous-sounding. The thing is, your tax documents or sexy pictures aren’t actually secured by putting them in the folder School/2017/Physics/Experiments. In fact, they’re just hidden. This resembles adding security to them, but isn’t quite the same thing. All that’s been done is that its slightly harder for someone to find them. This is the heart of security through obscurity’s benefits and downsides.

Let’s go back to the car. Leaving your valuables locked in a car’s trunk is better than having them visible. With them visible, an attacker knows what they’re going to get. Without them visible, they’re no harder to get, but they’re harder to assess as valuable. But in any state of obscurity, you increase security of the valuables more by making sure the car is locked than you do by obscuring them.

This is similar for WordPress. Let’s say that you want to make it more difficult to find out that you’re running WordPress. Common advice is that you should hide “Proudly Powered by WordPress”, the meta generator HTML headers, and a few other things. All of these are supposed to make you more secure. But none of them is near as valuable as making sure that you lock the metaphorical door.

Specific Common WordPress Security-through-Obscurity Advice

I started above to enumerate some of the security-through-obscurity advice you might see around the WordPress ecosystem. Here are the big ones:

  • Hide “Proudly Powered by WordPress”
  • Hide meta generator tags
  • Hide WordPress version
  • Remove readme.html
  • Hide login page at a different URL
  • Rename wp-admin, wp-content, etc folders

All of these steps will, like relocating your valuables out of view, make it a little harder for an attacker to discern that your site is running WordPress, and possibly have some other minor benefit. But none of them are good enough to be recommended steps to improve the security of a common WordPress site.

None of these practices are good enough to be recommended steps to improve the security of a common WordPress site.

With each of these steps, you’re only protecting yourself from a specific type of attacker: one smart enough to run an attack, but foolish enough not to have a more robust way of trying discern and take over a WordPress site. Let’s take the most simplistic piece of advice in this genre: making sure that you remove the theme footer that possibly mentions WordPress. This would be useful if your opponent in the security arena is someone who’s literally Googling to find WordPress sites to attack by searching for that string. But such an attacker won’t get very far in the world.

The other tricks will get you a bit further. For example, if you’re fighting off an attacker who’s smart enough to look for readme.html files, you’re dealing with someone who’s at least a level more sophisticated. So that’s a little more worthy of your time. And I think that moving your login URL would slow down enough of the attackers in the WordPress sphere that you’d really get some benefit from the practice.

At the heart of all of these pieces of advice is the thought that an attacker shouldn’t know you’re running WordPress, then you’ll be safe. But the thing is, none of these alone stops a sophisticated attacker from knowing that you’re running WordPress. So long as your stylesheet is called style.css and has the Theme Name text within it, it’s pretty clear you’re using WordPress. Because we’re running minification and concatenations of our stylesheets on WPShout, we’re not offering the so common style.css tell. But we’ve still got a telling Theme Name showing in a stylesheet on our site. If I were an attacker, that last method is what I’d rely on to find WordPress sites. (Though looking for the REST API, XML-RPC, or a couple HTML markup bits that are less commonly used outside of WordPress are also good ideas.)

Why Security Through Obscurity is Useful

It is true that if you make it harder to tell that your site is WordPress, you’ll probably stop some number of attackers from trying your site.

I’ve titled this article, and written much of the above to tell you how useless these security through obscurity techniques are. And I genuinely think that they lack a compelling story about why they’re worth doing. But I can’t deny that they have some value. I don’t think it’s wise to recommend them because of their cost in effort and minimal benefit, but they aren’t useless.

It is true that if you make it harder to tell that your site is WordPress, you’ll probably stop some number of attackers from trying your site. Whether that’s one of the thousands of them, or 100%, is all speculation when we lack data. And we just don’t have data.

But I do think that some of the benefits are clear. I can see a hacker constructing a script to probe a long list of sites for readme.html files that suggest the sites are WordPress, and then only attacking those that do indeed contain that file. So if that happened, there would be incontestable value in having removed yours. Then that attacker wouldn’t make any further effort to attack your site (as a WordPress site).

Similarly, it’s easy to imagine an attacker writing a script to visit all those WordPress sites and pointing it at {url}/wp-login.php to attempt to brute-force log in. If you’ve hidden your login page by putting it at it’s really unlikely that they’ll successfully try to log in to your site.

So some of these things are useful. Fundamentally, a multi-layered security plan does include making it less likely that people even try to access things you don’t want them accessing. So these measures are worth taking for some people. I just think they’re a lot less valuable than the frequency of their being given indicates.

Why You Shouldn’t Waste Time with Obscurity Techniques

The core issue here is that obscurity can make sense as a layer in your security practices, but is not itself a worthwhile security practice.

Fundamentally, given a choice between pursuing security through obscurity, or substantive and useful techniques that ensure that your WordPress site is properly configured, that the file permissions are locked-down, that you don’t have old user accounts with inappropriate levels of access, etc is much more important.

We talked in the last section about attackers who might be slowed or stopped by taking the steps of security-through-obscurity. But it could also makes sense for our theoretical attacker to ignore any type of check to see if a site is running WordPress, and just indiscriminately attack all the sites in a list of URLs they’ve assembled as if they were WordPress sites. The percentage of WordPress sites in the world is high enough that that could be just as smart as probing.

The core issue here is that obscurity can make sense as a layer in your security practices, but is not itself a worthwhile security practice. The distinction can be drawn between things that meaningfully make it harder for people you don’t want to to access a resources, and things that just make it a little harder to find the resource. Security through obscurity is by definition the latter.

But At Its Heart, Security Is About No Single Thing

This whole point is, I’ll admit, a bit of an academic distinction. There’s literally no way to guarantee that a site (or anything else) is completely secure. That’s the reason that a security plan that includes multiple different steps of protections is so important. Your goal, in securing any WordPress site, isn’t to achieve perfect security, but to take action to mitigate the threats that you think are most important.

I can’t argue with the fact that if an attacker can’t find a way to log in to your site, the likelihood that they successfully log in goes down markedly. Actually, infinitely. (Though, it’s worth realizing, you may also struggle to find your login page at some point…) Or if your attacker doesn’t know you’re running WordPress, they’ll be less likely to succeed than they would in attacking a known system.

So if you want to do these things on an idle Tuesday, do them. Hide the meta-generator. Move your login URL. Hide the WordPress version. Even change your database prefix. Many of these step do have some (very) small benefit, so they can make sense as part of a comprehensive plan to harden and protect your site.

But so are a load of other, more practical, concrete, and useful practices. You’ve heard of those too: check file permissions, run updates, have good passwords, disallow file edits in the admin, and more. Understanding the real benefits and risks to a site are what’s important. Then: find various methods of securing yourself against those risks. And to really do that you need a lot more than a little bit of added obscurity.

I’ll be talking more about WordPress security in the coming weeks (including updating our huge WordPress security guide), ahead of the launch of WordPress Security With Confidence, my new course which (in developer and non-developer flavors) teaches you everything you need to confidently navigate the world of WordPress security. You can take a look at the course here.

4 Responses


  • Great points overall David. I do find those particular “obscurity” measures to be meaningless — with one exception. Attackers most definitely target wp-login.php and /wp-admin as attack vectors. But, just moving it to some other relatively discoverable url doesn’t help. What does help is a combination of the following:

    1) Move the login to a URL which isn’t obvious and doesn’t show up in your sitemap, and make sure the previous login url triggers a proper 404 response.

    2) Automatically ban an IP if it hits the old login url and provokes a 404 too many times in rapid succession

    This can help prevent brute force attacks and prevent that IP from attacking other parts of the site.

    But your point at the end is great. When it comes to security, there is no silver bullet — no single thing. Thanks!

  • Greg says:

    Hiding various WordPress markers isn’t really security by obscurity though (in my opinion).

    When I think “security by obscurity”, I think more of, say, programming my own custom PHP site with a log in and access control system that I develop myself.

    Now on the one hand, that’s a terrible idea, because my roll your own system is very very likely to be more insecure that a system developed by lots of developers over years in widespread usage, all while being hammered on by attackers (and hardened against them).

    On the other hand, it’s not going to have the *same* vulnerabilities as every single installation of the same version of WordPress. So the automated scripts that scan every site for vulnerabilities are not going to find the WordPress vulnerabilities on my roll your own site. *That*, for good or ill, is security through obscurity.

  • Hello,

    great read ! I especially like the fact you are not Manichaean which is sadly often the case with security blog posts.

    But I disagree on the login URL part for multiple reasons and namely because that’s an efficient way to fight against brute force attacks. WP native URL is a prime target.

    Thanks again for sharing this.

  • Adreen says:

    Move `wp-config.php` to above WordPress installation directory also “security through obscurity”.

    It should be stopped.

Add a comment