We have done a number of tests of WordPress security plugins to see if they protect against exploitation of real vulnerabilities in other plugins (and really should do some more). That the results of that testing showed that those plugins provided little to no protection against exploitation of the vulnerabilities wasn’t all that surprising to us, for a number of reason, including that we are often brought in to clean up hacked website that had multiple security plugins installed at the time the website was hacked. Something that really surprised us was the response from the developer of one of the plugins that provided no protection, BulletProof Security. They stated that “it is outside of the scope or intended purpose for any security plugins” to protect against vulnerabilities that exist in other plugins.

Based on their explanation of why that was, it would seem that would apply to other vulnerabilities as well, since they don’t believe any security plugin should interfere in the “normal functionality in any other plugins” and many, maybe most vulnerabilities, involve misuse of normal functionality. That misuse could be due to either someone who is not intended to have access to the functionality, accessing it, or the functionality being used in a way it isn’t intended to be. Considering that protecting against vulnerabilities in other software on the website being exploited is one of the few things that security plugins could actually do to protect a website from real threats, we wonder what it is the plugin is even supposed to being doing to earn the name BulletProof Security.

The problem with this sort of thing is that you have lot of people, the plugin has 100,000+ active installs according to wordpress.org, using a plugin promoted as providing bulletproof security when the developer isn’t even attempting to provide that. That sort of thing makes it harder for people to find that there are solutions that address real issues. As an example take a look at a recent comment on our post about the developer of that plugin believing it is outside of scope to protect against plugins vulnerabilities. To a large degree that commenter is basically describing what our service does, but as if it something that isn’t being done and would be difficult to do.

Here is what the commenter said that they believe we are expecting security plugins to do:

a) monitor the security flaws of *other* plugins (given there are probably hundreds and hundreds of them with major bugs),
b) and then create exceptions for these issues, and
c) then have to provide support to their customer base for those issues as well.

We do both “a” and “c” as part of our service. For “b” we instead try to work with developers of the plugins to get the vulnerabilities fixed, which when that happens helps even those not using the service. When vulnerabilities are not fixed then “c” comes in to play as we are available to work with customers to decide what is the best action to take in their situation. It might be that they can safely ignore a minor vulnerability (not all vulnerability impact everybody’s use case), we might be able to provide a workaround, or it might be that the plugin is so insecure that the best course of action is to remove it. We also provide data on the vulnerabilities in plugins that we see are being exploited in the free data that comes with our service’s companion plugin, so those not yet using our service can be warned when those type of vulnerabilities have not been fixed as well.

The commentator then claims the following problems with doing what they say we are suggesting:

1. Security plugins which are based on identifying illegal behaviours cannot be expected to be blocking what is essentially *normal & legal* functionality which is now insecure due to the poor coding of a 3rd party plugin. This would mean that they are essentially writing one-off specific case code for individual plugins and having to maintain that in their plugins. What a nightmare that would be for them.
2. They would need a team of people just to identify and test for 3rd party plugin code bugs and security issues. Purely from a business perspective, I cannot see how it would be viable to provide this based upon the costs of maintaining a security plugin in the rapidly changing WordPress ecosystem, notwithstanding that there are probably thousands of free plugins that are horribly written.

We avoid problem one by working with developers to vulnerabilities fixed, it should be noted that other companies promote services that with claim they do what is described there, but from what we have seen they don’t it very well.

For problem two, we actual already do this.

If there were less products and services out there promoting themselves in ways that are wildly inaccurate (the Wordfence Security plugin is promoted in part as “Powered by the constantly updated Threat Defense Feed, our Web Application Firewall stops you from getting hacked.”, despite that it couldn’t possible stop a lot of hacks) it would probably be easier for us to get more customers, which could allow us to expand what we are doing to address the security issues with plugins (for example, expanding the frequency of security reviews of plugins that we do).