When it comes to determining if a WordPress plugin is secure or not, there is a lot of bad advice out there, much of it coming from security companies you should be able to trust to give good advice. For example, a plugin not having been updated for a certain period of time doesn’t mean it isn’t secure, as someone recently suggested might be the case with a plugin:

Please, can you update the plugin and check is all good? my site is hacked may is cause your plugin don’t update for 2 years.

It is true that if the developer isn’t supporting the plugin, then if a vulnerability was found, it likely wouldn’t be promptly fixed. But that doesn’t mean the plugin is insecure and another plugin that is still being updated might be less secure.

For those dealing with a hacked website, as that person was, trying to look for a security issue in plugins being used usually isn’t a good way to try to determine how the website was hacked. Instead, you would want to bring in someone who has expertise in reviewing log files and other evidence, to determine the source of the hack (something supposedly reputable security providers often don’t do).

But what about those that want to proactively improve the security of their WordPress website by checking over the security of the plugins they use or are considering using? The reality is that there is a limited amount that can easily be done, which might explain how often bad advice involves easy to do things. Let’s look over things that are useful and that are not.

Stats Are Not Helpful

A lot of the simple advice involves looking at various stats for plugins. Things like the install count of plugins, number of reviews, and the star rating of the reviews. What the advice doesn’t provide is any evidence that those things correlate with the security of a plugin. And it isn’t hard to find examples of where those stats don’t correlate with the security of plugins. For example, it isn’t uncommon for plugins with millions of installs to have vulnerabilities, even what appear to be zero-day vulnerabilities.

Developer Claims Are Not Reliable

It isn’t uncommon to find WordPress plugin developers making strong claims about their handling of security, but in our experience, those developers often don’t appear to even much of a grasp of security. We often run across those sorts of claims when we are trying to get in touch with a developer to let them know that they failed in an attempt to fix a vulnerability, which is a pretty bad sign as to their understanding and handling of security.

Vulnerability Listings

It isn’t hard to find data on claimed vulnerabilities that have been found in WordPress plugins, but that data has limited value in trying to determine if they are secure, for multiple reasons:

• The data is usually highly unreliable. Contrary to how these data sources are sometimes marketed, the data often hasn’t been reviewed for accuracy. We often find that claimed vulnerabilities don’t exist and it appears the providers claiming otherwise don’t have much understanding of security.
• In plenty of instances, whether the vulnerabilities are real or not, they haven’t actually been addressed, despite a claim from data providers that they have.
• Even if the data was accurate, it only reflects vulnerabilities that have been found. There is very little in the way of systematic checking of the security of plugins, so it is possible that a very insecure plugin would have no listed vulnerabilities, while a secure one would have them.
• It is historical information. Many vulnerabilities found years ago don’t necessarily tell you anything about the current state of the plugin. It isn’t uncommon for plugins to be substantially re-written, so the previous security or insecurity of the plugin might not reflect on its current state.

Automated Security Tools

There are a lot of automated tools for checking over the security of software. If there was something that existed that both correctly identified most security issues and didn’t produce a lot of false positives, then plugins wouldn’t still be insecure as they are. Automated tools in the right hands can provide useful information for further investigation of the security of plugins. In plenty of instances, though, they can lead to people thinking they have secured plugins when they haven’t.

Penetration Testing

Penetration testing is at best an inefficient way to check the security of plugins, as it involves using less than all of the available information to try to determine the security status of a plugin. So it is both more difficult to identify real issues than it could, while also being unable to spot other issues, that can be found through a security review of a plugin.

That is the best case scenario, much of penetration testing looks to be done using automated tools that largely will identify known vulnerabilities in outdated software (or at least claimed vulnerabilities).

Either way, it is likely to produce poor results for a high price tag, so it isn’t a very good option.

Developer Advisories

What we have found in dealing with the security of WordPress plugins for years is that there are some developers who either are unwilling or unable to secure their plugins. We have even found developers introducing new serious vulnerabilities that are substantially similar to vulnerabilities that they know have been exploited in their plugins. Avoiding plugins from those types of developers is a way to avoid some plugins that are likely to be insecure without having to do a lot of investigating in to the plugins. We provide warnings about developers we have run across with repeated problems and information on those is available in multiple forms.

Security Reviews

If you want to get a good understanding of the current state of the security of a plugin, then a good security review is the only real option. A problem with that is that can be expensive depending on the complexity of the plugin. Another problem is that there are people offering to do security reviews that don’t appear to have a good grasp of security. We have run across companies and individuals offering to do those, while we were trying to contact them about a security vulnerability in their own software.

We would recommend only hiring someone to do a security review that has public results of previous reviews that could be checked over by a third-party.