When it comes to protecting WordPress based websites against the threat of plugin vulnerabilities, there are a lot of options available. Like security solutions in general, most of them are not going to do a very good job of what they are possibly capable of. If they did, then security would be in much better shape than it is. Making things worse, oftentimes security solutions are treated as if they are a solution for problems they are not. Recently we had someone mention to us that a client of theirs had chosen a proxy based WAF over using our service for protecting against WordPress plugin vulnerabilities, which is odd since the two things are quite different. A proxy based WAF isn’t a good alternative to a service like ours for a variety of reasons.

What is a proxy based WAF? WAF is short for web application firewall. Like a lot of security terminology, the term is often misused. An actual WAF is a security system that is separate from the software running on a website. So a WordPress firewall plugin wouldn’t be a WAF, though, those are often mislabeled as WAFs. A proxy based WAF means that website’s traffic runs through the WAF before reaching the website. That tries to stop attacks before they reach the website. These days when someone just says WAF, they are talking about a proxy based WAF.

WAF’s Black Box Protection

How much protection a proxy based WAF could provide against WordPress plugins varies widely. For example, if the developer was keeping on top of WordPress plugin vulnerabilities, they could write rules to protect against a lot of them once they are publicly known. They could, but they probably are not. Consider Cloudflare, who are frequently touted as a good security solution for WordPress websites and have the scale do to a good job of writing rules. As we have documented in the past, they are not actually writing rules for WordPress plugin vulnerabilities.

With Cloudflare, they publicly disclose what rules they are adding. Other providers don’t even do that, so you can’t see what they are or are not doing. It’s unlikely that they are doing a better job if they won’t even share basic information on what they are doing.

Not only are providers not providing that sort of information, they are not providing evidence that their solutions provide effective protection. Either they are not measuring how good a job they do or they are, but are not releasing the results. If there were good results, it seems highly unlikely they wouldn’t promote that.

WAFs Have Limited Information to Work With

Even if proxy based WAFs were well developed, they are not going to be able to protect against a lot of WordPress plugin vulnerabilities. At least, not without blocking a lot of legitimate requests as well.

One significant advantage that WordPress firewall plugins have is that they can tie directly in to WordPress, so they can have access to information that WAFs don’t have. While most firewall plugins don’t take advantage of that, the best ones use that to understand what permission someone has on the website and they can see actions as they occur in WordPress.

The practical implications of that came in to play in June when a WAF provider closely tied with WordPress admitted that they failed to protect against a zero-day vulnerability, while two firewall plugins did because of the additional information they had access to. A zero-day is an unfixed vulnerability being exploited before the developer is even aware of it.

Considering that once a vulnerability has been fixed, the best option to protect against it is to update the software, firewalls are best utilized to protect against zero-days. WAFs are not a great option for WordPress websites since they have less information to work with than a well-developed firewall plugin.

Unlike WAFs, there is public testing to see whether firewall plugins are able to provide protection against WordPress plugin vulnerabilities.

Dealing With Vulnerabilities at the Source

While well developed WordPress firewall plugins can provide significant protection against types of vulnerabilities that are widely exploited, there are limitations on what they can do. The best approach to protecting against WordPress plugin vulnerabilities is for there to not be vulnerabilities in plugins being used. If that was easy to do, then there likely wouldn’t be many, if any, vulnerabilities still in plugins.

At best, proxy based WAF providers could provide indirect help by catching zero-days and working with WordPress plugin developers to fix those, but there doesn’t appear to be much of that happening.

A common solution to more directly address this is a service that warns about known vulnerabilities in WordPress plugins. There are a lot of options for that type of data, but based on our years of experience in that space, the data is usually not very good. In one recent example, after finding that a developer had failed to fix a vulnerability in a plugin used by at least one of our customers, we found that other providers were claiming it had been fixed. As we said in the introduction, security solutions are generally not doing a good job.

Using a service that has accurate data on plugin vulnerabilities is a good way to help address plugin vulnerabilities. For those with a larger budget, getting security reviews done would help even more.

When Using a WAF Makes Sense

Based on what we have mentioned above, we hope it is clear that a proxy based WAF isn’t a good solution for protecting against vulnerabilities in WordPress plugins. We really shouldn’t have to have said that, as the onus should be on the providers of WAFs to show they provide good results, but that isn’t how things go and security is much worse off for that. So when would a WAF make sense? Assuming the developer could show that it can provide effective protection with what it could offer, then it would make sense when there are not specialized solutions, like our service for WordPress plugin vulnerabilities.

So what about using a WAF in conjunction with another solution as an extra layer of protection? If you could find one that provides evidence of effective protection, which means not only stopping attacks, but not blocking legitimate requests, then it wouldn’t be a bad idea if you want extra protection.