WordPress sites are one of the most common targets for attack on the internet. They’re hacked more than any other type of site. If you, your friends, or someone you know has never had an experience of a WordPress site getting “hacked”, you’ve either been extremely lucky or have abnormally careful people surrounding you in your life.

Security matters because WordPress sites are online, are running literally hundreds-of-thousands of lines of code, and WordPress is a common-enough platform that it’s going to be targeted by attackers. When Microsoft Windows was a relatively new and dominant platform with regular headlines about security issues, its defenders pointed out that the number of attacks was a big reason. While there were security mistakes being made by Microsoft, it was also the case that many security errors which were commonly exploited first on the Windows platform.

So too with WordPress. WordPress powers about 27% of the internet. That’s great, but it also means that if someone finds a fundamental security flaw that’s common on all WordPress sites, or even a big percentage, they can easily have thousands of servers mustered in a matter of hours. That’s why WordPress is such a big target, and why we must take WordPress security seriously. It’s important stuff.

Want to Become a WordPress Security Expert?

WordPress Security with Confidence

WordPress Security with Confidence is our comprehensive guide to WordPress security.

Starting with general security principles, and advancing to very specific actionable steps, we explain all the details you need to understand in clear, jargon-free language. It’s your essential companion on WordPress security.

Become an absolute expert, and gain the confidence that you’re doing WordPress security right.

Learn More

This Guide Really Isn’t Complete; No List of WordPress Security Best Practices Can Be

I realize the title of this page is a little grandiose. “The Complete Guide to WordPress Security”. P-sha!

This literally isn’t the complete guide to WordPress security, because security is a continually evolving practice and not a defined and narrow set of rules. It’s simply not the case that you can ever install a single plugin, follow three simple rules, or do anything else that is severely constrained in time and know that something that is on the internet (like your WordPress site) is completely secure.

Things in boxes 400 feet underground in the middle of the desert where no one knows they are very secure. But they’re also very useless. Things on the internet, like WordPress sites, have a complex and continuously changing risk environment that they must be protected from. So we’ll keep this page up-to-date over time, and we think that it covers all the basics and lot more. But I join you in doubting our “complete” and “final”-ness.

Why You Should Trust Me on WordPress Security

Me (right), with WordPress co-founder Matt Mullenweg (left!)

Hi, I’m David. Late in 2017, I decided to put together a course all about WordPress security. I felt that too many people I knew, including me, were struggling to differentiate the truth about WordPress security from the fiction. Plugin vendors, people selling other platforms, and others say a lot of negative things about WordPress security. We often call this stuff “FUD”, which is usually understood to mean “unfounded fear, uncertainty, and doubt.”

I wanted to settle for myself and everyone else what steps for securing a WordPress site were worth doing, and which are silly and outdated advice. From that came WordPress Security with Confidence. It has hours of video, which were a result of hundreds of hours of research. I also talked to some of the top voices in the WordPress security arena to hear their diverse opinions on the topic and help to separate the good advice from the bad.

“I Heard It’s Insecure…” Is WordPress Secure?

One of the most common reasons people start looking into the security of WordPress, and the best practices for WordPress security, is that they either doubt that WordPress is secure, or they hear from someone who insists it isn’t. As I mentioned above, there is a lot of FUD around WordPress security. There are tons of people selling you something — Squarespace, a WordPress security or hosting plan, a password manager, whatever — who try to exploit and not end your ignorance. (My goal is eliminating your ignorance, or at least minimizing it.)

The heart of answering this question comes down to defining your terms. WordPress is a vast ecosystem with a huge varieties of habits of practice and different configuration. There are absolutely WordPress sites out there today that are insecure and which are likely to be hacked in the next 24 or 48 hours.

But if we mean “WordPress” as that core piece of software contained in a zip file that you downloaded from WordPress.org, I think it’s pretty completely secure. On any given day, there’s a 0.00001% chance of an unpatched problem in that WordPress software is being attacked in the world.

WordPress now comes with built-in auto-update, and most hosts have the ability to make sure that your site gets patched if that fails. This is crucial, because WordPress 4.9.1 probably has a security problem that someone will find in the next months or years. But WordPress the organization is staying atop those newly discovered issues, and making point releases like 4.9.2 or 4.9.20 that fix those sorts of issues.

WordPress the tool is secure if you stay up on the latest versions. And if you make sure your site’s on hosting you trust, with updates to trusted plugins installed, it’s completely secure. But when those things aren’t done, it’s absolutely possible that a given WordPress installation is insecure.

The Real Threat to WordPress: Botnets!

WordPress sites are, generally, not at risk because a single person anywhere is trying to bad things to one of them. Quite the opposite in fact. There is a possibility that you have a single person trying to breach your WordPress site, but unless you’ve recently angered your techno-wizard niece, you probably don’t need to worry about that.

The real thing that regularly threatens and harms WordPress sites is instead automated attacks by people trying to take over your site. People control these attacks, but they are completed by computers. No person is trying to log in to your WordPress site themselves with various usernames and passwords.

Instead, they write programs to scan the internet for WordPress sites and try to log in to all the ones they find. Or try to exploit known plugin vulnerabilities on all of them. When you understand that your threat model mostly consists of automated attacks on WordPress sites from non-human actors, a different set of security practices become important.

Why WordPress Sites Get Hacked

So, we mostly need to worry about botnets, rather than single people. Why are botnets trying to take over your little WordPress site. After all, it’s just your website to…

• share pictures with friends
• sell your pet carriers online
• write for fun
• etc

Botnets don’t really care what your site is for. If you have an insecure WordPress site, they’ll take it over. Their motives differ, but the most commonly seen reasons that a WordPress site are taken over are things like:

• Forwarding traffic to their own site(s)
• Taking over your SEO rankings to send Google-juice to their pages
• Defacing for pride or political messaging
• Drive-by-downloads — making visitors to your site download malware, etc.
• To back-door your site for later use
• To gain access to your site data — user lists, purchase history, etc.
• Sending spam — if your WordPress site can send email, they can use that sending for their emails too
• To use your server resources (CPU mostly) to do useful computation, most likely mining crypto-coins like Bitcoin

Those are just the ones I could think of from a bit of thinking and research. It’s quite possible that a clever hacker has even more they’d add to the list.

What I hope the list makes clear is that your site’s relative obscurity isn’t protection. Surely you may not have an interesting user list, but you do have a server which can be used to make Dogecoins or to send spam. Because every server has a CPU, and the vast majority of them can send email.

WordPress Security Relies on the Whole Stack, Not a Single Thing

Another important thing to realize about WordPress sites is that WordPress really sits atop a large variety of technologies, and the other parts of the stack can also have vulnerabilities. For example, WordPress runs atop PHP. Just as with WordPress, sometimes versions of PHP contain security vulnerabilities. If you’re updating regularly, they’re no big deal. If you aren’t, those PHP issues can compromise your WordPress site.

There’s also the possibility that something else in your WordPress site’s underlying security stack is misconfigured. This is different than being out of date, but has a similar effect. If you’re new to configuring web servers, you may make a change that seems to be necessary to get the thing working without realizing that it will have profound negative security implications. It’s more common than you’d hope, and is one of the big reasons I like to leave as much of the non-WordPress configuration to professionals.

I’m not saying that you can’t set up your own physical server yourself, or buy a cheap VPS and set it up with someone else’s configuration script. But it’s really important to trust the configuration you run WordPress atop. Because if you do the WordPress right, but MySQL configuration wrong, very bad things can still happen.

Unnecessary (But Common) WordPress Security Recommendations

Before we get into the advice I want you to definitely follow, I want to 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.

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

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 an 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, more later.)

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.

General WordPress Security Best Practices

There are few common things you must do if you want WordPress to be secure. As I think about it there are a number of possibilities, but these are the things that you should always do. These aren’t in the most exacting of order, but they’re roughly in the order of relative importance I think you’ll want to give them.

I’ll also add that if you just do the first few of these, you’re ahead of 50% of the WordPress websites online. If you do the first five it’s unlikely that you’ll ever have an irrecoverable security problem on your WordPress site, and if you do them all I’d be pretty surprised if you had a site compromised. That is not a guarantee, it’s just how I think about it.

Do: Have Good Passwords for WordPress

The basic way that every WordPress site on the internet could be attacked is pretty simple: bots guess account passwords regularly, on almost every WordPress site online. You have a bad password, you’ll likely lose your account, and thus your site. Some obviously bad passwords:

• password
• p455w0Rd
• [sitename]
• charlieiscute

There are lots of different schools of thoughts about what makes a good password. But pretty much everyone agrees that these are bad. All of these are bad because it’s pretty easy for a password-guesser to hit them. “password” and it’s variants—even those cool, clever, character substitutions—are always high on password-guessing script’s list to try. Site names are also great to guess. And by “[sitename]”, I mean something like “WPShout” or “wpshout” as the password Fred or I have here on WPShout.

“charlieiscute” has some big advantages over the others. It’s not a dictionary word, for one. It’s longer as well. And after all, most people think that Charlie is handsome and not cute. (That is a joke. I don’t know Charlie.)

The nice thing about “charlieiscute” is that it’s long. It’s also a little unique. But it’s not terribly hard to guess. It’s purely using lowercase letters. No uppercase, no numbers, no special characters. While the attacker is unlikely to know that, when you include other classes of characters, you make it more likely that a random guessing system will hit your password faster.

Steps to Beef Up WordPress Password Security

There are a number of things to improve your password security in WordPress. But here are the big three:

• Have a hard-to-guess password. Good passwords look hard to read and complex. Something like “RP@yu3ohd&LtpwzM}rWhgp6#AtY6HAzjvxKnz9zh”. This password is long, random, and unique. The likelihood that any attack script could guess it is low. And because it’s unique—it’s not also my password on Facebook, ArtWorld, RandomInternetReseller, or anything else—a compromise of them won’t compromise it.
• Slow down password-guessing attacks. By default, a bot can guess 1000 passwords per minute (roughly) on your WordPress site. That’s a lot. If you block people from continuing to try to log in after a set number of failed attempts–3, 5, 10, whatever–you’ll slow down an attacker a lot. My favorite way to do it is “Limit Login Attempts.” Here’s a Quick Guide explaining limiting login attempts in more detail.
• Use a password manager. If you’ve done the first thing above, you’re going to quickly get tired of typing that password, or you’ll forget it. This is where a password manager comes in. There are too many types of password managers for me to tell you which to use and why. I personally use and like 1Password, but your mileage may vary. KeePass and LastPass are other popular managers.

Do: Keep WordPress, plugins, and themes updated

The other way that every WordPress site online is almost guaranteed to be attacked by the swarming botnets is via attacks against known exploits in software it may be running. Whether or not you ever used Revolution Slider, TimThumb, or another famously hacked WordPress plugin, a bot likely tried to make use of the known issue in the old version of that software on your site. There’s a good chance that even though those exploits are now quite old, a bot is trying to attack a WordPress site with them now.

This is why you must keep WordPress up-to-date. And not just the core WordPress, but all the plugins and themes you use too. It’s more common for plugins to have security vulnerabilities today than either WordPress core or themes, but all three can. And when an outside researcher or inside developer realizes there was a security problem in some code in their thing, their most responsible course of action is to create a new version that doesn’t have that vulnerability. Most players in the WordPress ecosystem are good at doing this.

This is why you must do your part. When they offer updates with bugfixes or security patches, you must install them in a timely way. You can have WordPress install these updates for you, do it yourself, or use a remote WordPress management plugin like ManageWP. “Managed” WordPress hosts will take care of these kinds of things for you (we use and like SiteGround – see our SiteGround review for more info). You can also just hire someone to do it, if you can’t be bothered. But you really must do this if you’re serious about WordPress security.

Do: Make sure you’re creating regular, automated WordPress backups

One of the best things you can do to keep your site secure is to make sure that you’ve got data security for when something bad happens. What this means is that you should have at least one recent backup of your site that you can use to rebuild or restore if something bad happens.

VaultPress is a popular backup solution, and is included with Jetpack

The only way, I believe, to reliably have a recent backup of your site is to do it automatically. Because we’re human, and thus fallible, it’s highly likely that if you required that you hit 1-10 clicks in your WordPress site to have an up-to-date backup, you’d sometimes skip doing it.

That’s the reason that you should try to use a backup plugin. It should also, ideally, be one that backs up both your files (photos, PDFs, etc) and database. And it’ll ideally push that data off the server you’re hosting on, as that does the most to assure that a hack can’t easily drop your backups as well.

Because this is a post about WordPress security and not backups, I’m not going to make you a full list of all the options and what their trade-offs are. But I think that Updraft Plus, Jetpack/Vaultpress, and Backup Buddy are the ones that come to mind for me.

Do: Regularly Check up on your WordPress Site

This isn’t really something that can stop the first bad thing from happening your site. In fact, the reason it’s important that you stay abreast of the state of your site is, mostly, to stop worse things from happening. When you see weird things happening on your site, it’s easier to fix early. And the less bad effect—Google warning visitors about you, for example—that can happen from a site-takeover.

If you’re not regularly logging into your sites to update them, you should at least make sure that the public side of them looks good on a regular basis. And if you’re not able to do that, you should at least make sure that to an external service (like Pingdom) the site appears to be online.

What these things will do for you is make sure you can restore your backup into a new iteration of the live site if something bad or weird does seem to be happening. It’s not as good as nothing bad happening, but it’s vital for the site’s long-term health.

Do: Avoid Untrusted or Pirated WordPress Code

It was extremely easy to find pointers on pirated WordPress themes. You shouldn’t do this.

This one is not super important for most people. Most of us are using only software from WordPress.org, or developers we’ve hired/worked with, or from other reputable sellers. If you do all of those things, you can nearly not worry about this one.

This is mostly for people who are trying to save money by pirating plugins, themes, etc. Or people who are trying to save money by getting code from “plugin clubs” or other less-than-stellar sources. If you do that, it’s possible that that code is free precisely because someone has already put a security back-door inside of it.

It does, sometimes, happen that free WordPress.org plugins are taken over by bad actors and bad things are done with them. It’s fortunately rare, and the maintainers of WordPress.org are pretty good about making it right. But if you’re worried about it, the best step is to be a little more thorough in your consideration of whose plugins you’ll install.

Do: Further Enhance WordPress Log-in Security (HTTPS, 2FA)

One of the most common pieces of WordPress security advice is to get an SSL certificate. And it’s definitely a good step (and another reason we like SiteGround – they make this easy). But an important thing that too few people realize is that HTTPS/SSL doesn’t really secure your WordPress site, but rather communication between your site and you and your other users (read: buyers). So it’s super valuable, but not everything.

At heart HTTPS should be thought of as a secure tunnel between your site and anyone viewing it in a web browser. HTTP connections can be snooped by any of the various devices sitting in between a visitor and server. With HTTPS it’s (nearly) impossible for those people to snoop.

So the most immediate benefit of HTTPS is that your log-in credentials (or credit card credentials, etc) are safer. It’s less likely that someone snooping on coffee shop wifi, for example, will see your password. So you should by all means get an HTTPS certificate. But don’t think that’s it’s securing your real WordPress installation on the server in any way, because it’s not really.

Another step which is good but slightly inconvenient is to use two-factor authentication on your site. When you do this, you’ll need three things to log in, rather than two. Typically, we log in to a site with the username (or email address) and password. With 2FA you also need “something you have”, which today usually means a smartphone that can either be sent text messages or generate time-series code. In both cases, you’re most secure because a compromise of your password is insufficient to take over your account; they’ll need that 4 or 6 digit code too. There are constantly changing sets of plugins which give this feature in WordPress. At present, Jetpack offers this or you can use a standalone plugin.

Do: Control Access you Provide to your WordPress Site

Another really useful security practice is just be really thoughtful about who you provide what access to your site. This is more a combination of different steps than it’s any single one. But things that I think fit under this title are things like:

• Provide each user with a tailored accounts. Don’t have Jamal and Estrella both log into your site with an account with a username like admin or wpshout. Give each of them an account, and only offer their account with the access rules they need. Using WordPress’s user roles and capabilities, give Jamal the writer an “Editor” account, but Estrella your developer the full “Administrator” access. This is based on what’s called the principle of least access.
• Don’t let people have weak passwords. If you follow the advice above, you’ll also want to make sure that Jamal and Estrella don’t use passwords like newyork or gogators. You can do this via social pressure—just ask or tell them not to—or via a real enforcement mechanism, like a plugin.
• Don’t give too much access. By this I mean more obscure advice, mostly made easier with a security plugin. (Or if you’re a developer, setting some WordPress constants.) Things like disallowing file editing in the WordPress administration area, and making sure that you don’t give people web hosting or SFTP access who don’t need it also fit in this general umbrella.

Do: Install a WordPress Security Plugin

There are a number of good WordPress security plugins. Which specific one you should use is a topic for a possible future article I write or public resource I create. But a good security plugin is likely to help you with a number of common security needs that we’ve list above (and a number will help with things I’ve omitted from this article, or put in the not-useful class).

Names that immediately come to mind for me a Sucuri, WordFence, Jetpack Protect, and iThemes Security. There are others, and as that list is meant as a starting list for your research, not the final list, please don’t read meaning into its order.

Plugins will do many things for you. They’ll make access logs for you, block known bad actors, can limit login attempts, and can help you fix more esoteric things like file permissions issues on your site. WordFence and Sucuri (in different ways) also provide a helpful bad-traffic-blocking mechanism for getting rid of botnets called a “Web Application Firewall.”

Security is Hard, Hopefully this Helped

This post is about 5000 words long. That’s a lot of words. And if you’ve skimmed well, or (better) read carefully, I hope that you’ve learned a lot. As I mentioned at the outset, I don’t feel that this is really the complete guide to WordPress security. I give that title to my course, WordPress Security with Confidence. But I think we’ve covered most of the major best practices for WordPress site owners.

If you’re a developer, there’s a whole other genre of best practices for WordPress security you need to learn about. You can get many of the details for free in my article “Principles of Secure WordPress Code,” and I’ve got even more details in WordPress Security with Confidence.

For a list of 5 biggest security steps we must take, as well as 8 other smaller security tweaks we can employ to put our security over the top, check out this great article put together by Cloud Living.

I hope you take the good advice here to heart. WordPress security starts with being up-to-date and using strong passwords. From there, most of the rest is useful but not necessary, because WordPress itself is pretty secure. But backups are required for real confidence, as is watching your site, being proactive about user controls, and having a security plugin. But there’s a lot more advice you’ll hear out there in the world, and while it’s not useless, I really don’t recommend you spend time focusing on it.

Making your WordPress site completely and forever safe is impossible via a single process. Instead it’s a continually evolving and changing task. Stay abreast of the news in WordPress, and think about what it means to your site’s security, and you’ll learn so much more doing that than you can in this or any single article on the topic. Cheers!