The question of whether or not WordPress is secure is complicated. While it’s obviously a secure enough platform for roughly a quarter of all websites around the world that are powered by WordPress, it’s not without its flaws.
So, who is responsible for keeping WordPress secure? Of course, some of that responsibility ultimately falls on your shoulders. That’s why it’s essential to be aware of and abide by WordPress security best practices in order to keep every site you build as secure as possible.
However, the team behind WordPress does have some responsibility in all this, too. After all, there’s nothing you can do to protect the underlying core of WordPress yourself.
If the matter of WordPress security nags at you as much as it does pretty much everyone else trying to conduct business online, then keep reading.
I’m going to cover some of the history around WordPress security issues and what the WordPress Project is doing about them.
A Brief History of WordPress Security Issues
Did you know that “[h]ackers attack WordPress sites both big and small, with over 90,978 attacks happening per minute”?
The issue isn’t necessarily that WordPress is a weak content management system, prone to hacking attempts and security breaches. It’s more likely a problem of visibility. WordPress is the most popular CMS around the world, so of course, it’s going to be an easy target for hackers.
WordPress is commonly discussed online (in blogs, forums, podcasts, and so on) so, consequently, the weaknesses of the platform are well-known. It would make sense then that hackers would primarily target WordPress websites, right?
Security is a major topic of discussion for any WordPress or web development blog, WPMU DEV included. That’s not to say that we’re to blame for publicly sharing WordPress’s flaws. In our community, this is mostly just common knowledge anyway. However, all this published information does make WordPress’s vulnerabilities painfully clear.
According to the WordPress Project (the team responsible for managing security for the platform), they issue security patches all the time. You know those automatic update notifications you receive when you log into the admin area? “WordPress has been updated to 4.7.2” or something like that? Well, usually when you see those minor versions go out, it’s because the team had to fix a security issue.
And these happen often:
The Panama Papers data breach from 2016 was, in part, traced to a vulnerability in a WordPress slider plugin.
This rundown from WPMU DEV covers a number of other documented WordPress security exploits. They might not all be as high-profile as the Panama Papers one, but it’s still concerning to know that, despite the WordPress Project’s best efforts – as well as the developers responsible for maintaining their plugins and themes – hackers are still finding a way in.
That said, it is reassuring to see how WordPress handled a very recent and far-reaching security breach stemming from the REST-API.
Here’s how things went down:
- In January of 2017, WordPress released update 4.7.2. Nowhere in the list of updates or patches was the security patch mentioned.
- About a week later, WordPress notified users that there indeed was a security flaw detected and patched in that update.
- The reason they gave for the delay in notifying users? Because they wanted to give them time to update the core before attackers were aware that WordPress was aware of and fixed the problem.
Of course, that didn’t stop hackers from defacing 1.5 million WordPress sites in the meantime. There are also those WordPress users who never updated the CMS (or did it too late) who remained vulnerable to the attack.
So, even though a patch was eventually issued by WordPress and they handled the announcement of it with much-needed tact, over a million sites were harmed in the process. And, worse, many website owners continued to be unaware of this defacement even after it happened.
Security patches seem to be coming out more frequently, with 2015 receiving the brunt of the abuse. As more and more of these occur, it’s important for you to know who is responsible for securing WordPress and what you can do from your side of things to ensure those threats stay out.
What You Need to Know About the WordPress Project (and Security)
Here is what you need to know about the WordPress Project and what they are doing to maintain the security of the core.
The WordPress Security Team
First, let’s talk about the WordPress Project. This security team is comprised of about 25 individuals, all of whom are experts in WordPress development or security. Currently, half of the people on the WordPress Project work for Automattic.
This team of experts is responsible for identifying security risks in the core. They are also responsible for reviewing potential issues with third-party-submitted themes or plugins and making recommendations on how they can harden their tools or patch known breaches.
While they typically work on their own to identify and resolve these issues, they do, from time to time, consult with other experts in the field, especially those from security and hosting companies.
How WordPress Identifies Security Risks
As you’d expect, the WordPress Project team works like a well-oiled machine. Here is how the security risk identification and resolution process works:
- An issue is identified either by someone on the security team or from outside the team. Non-Project members can communicate these detected issues by emailing firstname.lastname@example.org.
- A report is logged and the security team acknowledges receipt of it.
- Team members then work together on a walled-off and private server to verify that the threat is valid.
- This is where they track, test, and repair any security flaws detected.
- The security patch then gets added to the next minor WordPress release.
- For less serious repairs, WordPress simply notifies users within the WordPress dashboard whenever an automatic release occurs.
- For more urgent issues, the release will go out immediately and WordPress.org will announce it on the News page of the website.
Of course, as we’ve seen with 4.7.2., WordPress doesn’t always immediately announce these security patches (for valid reasons), though they do always take immediate action to resolve them.
A Note About Automatic Updates
As of version 3.7, WordPress has had the ability to push minor updates automatically to all websites. This ensures that the WordPress security team can get urgent patches out in a timely fashion and not have to wait around for users to accept and make the update on each of their websites.
However, it is possible for WordPress users to opt out of these automatic core updates. If this is the case for you, please be aware that this may put your site at additional risk, especially if you don’t have the time to diligently monitor all your sites for the latest and greatest update.
WordPress Plugins and Themes Security
Much like how it’s your responsibility to provide visitors with a secure website experience, WordPress plugin and theme developers are responsible for keeping their users (i.e. you guys) safe as well. While WordPress cannot manage the tens of thousands of plugins and themes out there, they can at least keep a close eye on them to ensure nothing seriously insecure slips through the cracks.
The WordPress Project is the team responsible for working with developers when a security issue is detected. Before that, however, there is a team of volunteers assigned to review each and every theme or plugin submitted to WordPress. That team will work with developers to ensure that best practices are followed.
Nevertheless, security vulnerabilities may still arise and that’s when the WordPress security team needs to step in to:
- Provide documentation for WordPress developers on plugin and theme development and security best practices.
- Monitor plugins and themes for potential security flaws. Any issues detected will then be brought to the attention of the developer.
- Remove harmful plugins or themes from the directory if the developers are unresponsive or uncooperative.
WordPress will then notify its users via the WordPress admin when those security patches (or the removal of bad plugins and themes) are available.
OWASP’s Top 10
The Open Web Application Security Project (OWASP) Foundation was created back in 2001 with the purpose of protecting organizations from software and programs that could potentially do them harm. What you may be surprised to learn is that the WordPress Project aims to abide by OWASP’s Top 10 at all times.
The Top 10 is a list comprised by the OWASP of known and very serious security risks. Having familiarized themselves with this list, the WordPress security team uses those trends to define their own top 10 list of ways to defend the core. Currently, their goal is to protect the core from the following risks:
- User account management abuse
- Unauthenticated access requests to the WordPress admin
- Unwanted or unauthorized redirects
- Exposing users’ private data
- Requests for access to direct object reference
- Server misconfiguration
- Unauthorized code injection
- Cross-site scripting from unauthorized users
- Cross-site request forgeries whereby hackers misuse WordPress nonces
- Corrupted third-party plugins, themes, frameworks, libraries, etc.
WordPress Security Requires Your Vigilance
Having reviewed all this, it does put my mind a bit more at ease to know that there is a dedicated team working to keep the WordPress core secure at all times. However, that doesn’t mean I (or you) should be lulled into a sense of complacency.
As we’ve seen – even as recently as this past January with the 1.5 million defaced websites – no matter how good the WordPress Project is at monitoring and securing the platform, hackers will find a way in.
That’s why it’s important to play your role in all this and keep your sites secured from every angle. The Defender security plugin is a good place to start.
For more tips, don’t forget to subscribe to the WPMU DEV blog as this topic of “Is WordPress Secure?” and what you can do to better protect it will continue to come up time and time again.