Don’t Waste Your Time On These 4 Common Security Tips

Image of a mountain with the text "4 Unnecessary Security Tips - Caldera Forms"

By David Hayes

Posted On:

Following last week’s post about WordPress security, in this post, I’ll start with advice I see commonly in other places that I don’t see much point in doing. Most of this advice is nearly harmless to slightly beneficial if it’s done. But the reason I don’t recommend it is that its benefits (where they exist) are so small. And the possibility that spending time on them makes you ignore more-valuable security practices is big. You’re free to do these, but I just don’t think they’re worth the time invested because the gains they give are very small.

Don’t Bother: Hide WordPress Version

We’re starting with the most useless piece of common security advice—that you should hide your WordPress version number, or that you’re using WordPress. The second is very hard to do in a serious way, and the first is basically valueless.

Hiding that you’re running WordPress is hard, and most people are trying to do it merely by changing or eliminating a <meta> tag in their site. No reasonably intelligent botnet builder is going to be relying on that, and many webmasters of non-WordPress sites report that they see people probing their site as if they were WordPress anyway.An image showing WordPress screen: Add New Post

Hiding your WordPress version is even less-sensical. The idea is, again, that a botnet will check if your WordPress site is on a known-vulnerable version of WordPress, and then not attack you if your version number isn’t in that list. I’ve literally never heard someone say they have evidence that botnets behave that way, and I don’t know why they would. I’m certain that this is WAY less valuable than just being on the latest up-to-date version of WordPress, so do that instead.

Don’t Bother: Disable XML-RPC API And The JSON REST API

For people who only use their WordPress site as a web interface, and only want to, there’s no real harm in disabling WordPress’s XML-RPC API. XML-RPC is used by things like MarsEdit, the WordPress mobile app, and other similar tools to connect to your WordPress site. It now possible for those tools to rely on the REST API instead, although most haven’t been updated for that.

The JSON REST API is a newer addition to WordPress, but can serve very similar uses. Additionally, WordPress internally is working to better leverage the JSON REST API for features that provide richer interactivity.

Both of these APIs are ways that an attacker can go after your site. And there are known records of people trying these attacks in the wild. The reason I include these in the list of things I don’t recommend, is that both types of attacks aren’t super common. And both of the APIs are also very useful and you’ll probably find that something you try to do on your WordPress website breaks one day because you completely blocked these APIs.Cloudflare logo

The better solution is to get a web firewall. Ideally, your WordPress host already incorporates one for you. If they don’t, you can buy one yourself from people like Sucuri or Cloudflare. These should stop the possibility of bad traffic to the API endpoints, but let good stuff through. It’s not guaranteed, but it generally is a better solution than just turning it off.

Don’t Bother: Change The WordPress Database Prefix

Most people who’ve set up WordPress have seen a text field asking for the database prefix, and seen the value wp_ in it. WordPress stores your data — posts, comments, products, etc — in the database in tables that start with that prefix. The idea here is that the default value is less safe and you should instead make it something like jadfl_, which no other WordPress sites are likely to have.

The likelihood of this step protecting you is low. You’re specifically protecting against what’s called a SQL-injection attack when doing this. Few WordPress sites are compromised this way, but it is certainly a way that sites can be taken down. But in order for that to happen, you need to be running a version of WordPress or a plugin which is vulnerable to such an SQL injection attack. So if your plugins and themes and WordPress are up-to-date, you don’t really get much extra benefit from this.

What’s more, it’s very easy, if you have a SQL injection attack vulnerability in your site, for an attacker to list out your database tables. It’s not as fast as blindly assuming that posts are in a table labeled wp_posts, but the number of attackers who would assume that’s the location of your table and not verify it is probably a small percentage of those smart enough to make the attack in first place.

I think if you’re setting up a new site, or you find an easy way to change your database prefix, go ahead and do it. It’s a very slight win, but it is a win. But if your site is already running using the wp_ prefix, and especially if you’re not a developer, do not waste your time trying to do this.

Don’t Bother: Rename Your WordPress Login URL

The last piece of advice that I think isn’t really worth doing is to move your login URL from example.com/wp-login.php to something like example.com/my-secret-url-for-puppy-login. This is made easy by some security plugins, and it’s not a clear complete waste of time. I can’t dissent from the idea that if an attacker can’t find your login page, they can’t even try to make a brute-force attack on your passwords. (On that, later.)An image of calderaforms.com login page

The issue with this advice is that if an attacker finds it difficult to find the login page for your site, you (or a coworker, etc) might too. If you have a safe and reliable way to bookmark pages that you find easy to use, by all means, do this. It does have some modest security benefit.

But again, the benefit is not that big if you do a few other things right. If you’re making all accounts on your site have good passwords, it’s very unlikely that a password-guessing attack will succeed. What’s more, if you have some method to limit the number of login attempts that can be made against an account in a small window of time, you’re further decreasing the likelihood that a login attack succeeds. And those two together—good passwords and limits on failed logins—is much more valuable than an obscure URL for logging in to your site without those protections in place.

Don’t Bother To Do These Things

These things can help your WordPress site to be more secure, but there are things that are more worth doing than these. Don’t waste your time: only focus on doing things with higher gains.

In the next post, I’ll guide you to some WordPress security best practices. These are the things that can make a difference!