The various testing we do of WordPress security plugins shows that they often fail to provide protection against vulnerabilities in other WordPress plugins, despite it being possible for them to have provided protection against those vulnerabilities. So what is going wrong? We can answer part of that, as we have identified five issues that cause them to fail to provide protection when they could. But why those issues are not getting addressed is something that is much more complicated to answer, so in this post we will focus on the issues that cause a failure to provide protection.

They Don’t Have Any Protection

Many WordPress security plugins don’t actually have any protection against vulnerabilities in other plugins being exploited. That doesn’t mean the developers don’t promote the plugin as if it they do. One very popular plugin that doesn’t offer protection markets the plugin with the claim that with it you can “stop attacks on your website”. With another, less popular plugin, it is marketed with the claim that it will “prevent 0-day exploit attacks” despite not offering protection.

There isn’t an innocent explanation for developers of those plugins to be claiming to offer protection that they don’t offer. Either the developer is lying or they have no credible reason to believe that it offers protection.

Their Protection is Completely Broken

The most surprising issue is one that wouldn’t have occurred to us, but that the testing showed to be happening. That is, that plugins have protection, but it is completely broken.

In one case, we found that if we configured the plugin as recommended by the developer, the protection was broken for two different reasons.

In another case, we found that changes made by the developer broke all the protection had provided.

That the developers don’t notice this strongly suggests they are not testing out the plugins’ protection.

They Only Offer Protection Against a Limited Number of Kinds of Vulnerabilities

Once you get past the plugins that don’t offer any protection or have protection that is totally broken, you are left with mostly plugins that provide protection against a limited range of types of attacks. Among the types of vulnerabilities they lack protection against, but could, are some of the most widely exploited types. A lot of the work to provide protection against those has already be done for the developers, as other plugin developers have figured out that protection could be provided and have implemented. Despite that, we are not seeing almost any expansions of protection being made by most developers.

As an example of that, we did two tests six years apart of a type of vulnerability that is guaranteed to have exploitation attempts, arbitrary file upload. That allows a hacker to upload arbitrary files. Usually they would use that to upload .php files and then cause the code in them to run. In its common form, that is easy to stop from being exploited. Despite the ease of doing that, in a test we did last year, only 4 of 31 plugins provided protection. In a previous test we did seven years ago, only 3 of 12 plugins provided protection.

Configuring the Plugin to Provide Its Best Protection Isn’t Made Easy

Normally, in our testing, we try to enable any feature of a security plugin that might provide protection. That creates the possibility that our testing shows plugins offering more protection than they normally would. The risk of that varies. Recent testing we did showed that among the best performing security plugins some don’t require any setup beyond activating them to provide most or all of their protection, while others offer none without additional configuration. With one of those plugins, testing we did last year found that the plugin provides significantly less protection when configured with its recommended settings than how we configure it.

Their Protection is Only Active in Limited Circumstances

In some of the testing we have done, we have been surprised to see that plugins fail to protect against vulnerabilities, as we know that plugin provides protection for that type of vulnerability. In reviewing what happened, to make sure there wasn’t a mistake in our testing, we have found that the protection exists, but it isn’t active in situations it should have. What that indicates is that the developers are not doing proper testing. Once they have implemented protection for a type of attack, they need to test it out to make sure the protection works against real world instances of the vulnerability type. When they don’t do that, you get the lack of protection shown in the testing.

Avoiding These Pitfalls

With any security solution, what you want to look for is evidence, preferably from independent testing, that the solution provides effective protection. If you instead rely on vague marketing claims, you can end up, as many WordPress websites do, relying on a solution that doesn’t provide the protection it claims to offer and that other solutions do offer.

With WordPress security plugins, we do testing to see how our and other security plugins do. As far as we are aware, we are the only ones doing that type of testing. In line with that, what our testing shows pretty clearly is that other plugin developers are not doing the same testing, so the protection they offer is significantly below where it could be.

Your best option with WordPress security plugins is to stick to ones that testing show provides more protection than others. More awareness that these plugins are not delivering the results they could, likely would spur needed improvement. Spreading the word about our testing would help with that.

Contrary to a widely held belief, WordPress security plugins can provide protection that other solutions, including web application firewalls (WAFs) can’t. So relying on them instead isn’t the solution, especially when the developers are not showing any evidence they provide effective protection either.