Should Plugin Security Audits Be An Expected Best Practice?

In this editorial I’m suggesting that an independent plugin security audit should be considered a best practice for large plugins that have a premium version.

Code Review vs Independent Audit

It is already considered a best practice in organizations and projects to conduct code reviews prior to merging code into the main version that will be made live. This may be as simple as pair programming, where two developers sit side by side and the coder shows the reviewer the changes made and talks through them. Or, it might involve a senior member of the team doing a code “diff” on the merged version to see what changed since the last release.

There are several things at play here. First is that it is widely acknowledged that a developer cannot adequately review their own code. Just as when reading over a document for spelling and grammar, the author is often blind to their own mistakes. Second, the reviewer is checking that best practices and guidelines have been followed and observed.

It is easy to see the relevance of these points in relation to security. The author may have made a mistake that they overlook and /or they may have failed to observe guidelines and best practices for secure code. A general code review may or may not focus on security, depending on the skills of the reviewer. However, an independent security audit most certainly would do so.

A security audit is a review of the code, functionality, and configuration of a WordPress plugin in order to identify potential security vulnerabilities. An audit typically involves a thorough look at the source code, including any third-party dependencies it relies on, as well as an assessment of how the plugin interacts with other components of a WordPress site. The goal of a security audit is to identify any weaknesses or vulnerabilities that could be exploited by attackers and recommend steps to address any issues found. Ultimately, the goal is to ensure that the plugin is secure and can be used safely on a live website. A security audit should be conducted by those with knowledge of secure coding practices as well as the training and experience to read source code and spot issues.

Who Should Have a Security Audit?

While ideally all plugins should go through a security audit, it is not practical to expect it. Oliver Sid of Patchstack Security told me that they are often contracted to conduct plugin security audits. I asked him about the cost, and he said cost depends on the size of the codebase, with an average cost of 4-6 thousand dollars. Audits for larger plugins could cost $10,000 or more. That is an expense that many plugin developers on WordPress.org cannot afford.

There are more than 60,000 plugins hosted on WordPress.org. Many of these are free offerings with no premium upsell. However, unlike Drupal and some other open source projects, WordPress has embraced the idea of a freemium model where there is a free version and a paid version with more features, as well as premium only offerings. While many of these plugins have only a modest or mid-range number of installs, there are currently 61 plugins with more than a million active installs.

Here is the list from wp-rankings.com as of June 2, 2023.

I mentioned plugins with more than a million active installs because these plugins are often the target of hackers and because a vulnerability in one of these plugins puts a million or more websites at risk. Also, many of them have a premium version or some form of upsell.

I recently suggested to a representative of a large plugin team that they might want to consider a security audit. The response was that they spend a lot of money on security and because they are a large company, when there is an issue it gets lots of attention, however, he didn’t feel that their plugin had more issues than any other … but a few weeks later they had another vulnerability reported. I assume that if they had had a security audit, as I suggested, he would have told me they had.

I hope you see my points about the value of an independent security audit as well as how the value of one increases along with the number of active installs. There is another case that it would made sense to include, and that is the case of third party libraries that are used in plugins that in an aggregate have a million or more active installs. For example, when Freemius had a security issue a large number of plugins in the WordPress directory were temporarily suspended until they had updated the version of the Freemius SDK that they included.

From the Site Owners Point of View

Site owners and maintainers are often told to test updates on a staging site before making them live. When the release is a security fix, however, this presents a catch-22. Update and break the site, or don’t update and get hacked. This conundrum highlights the value of adaptive firewalls with virtual just in time patches, like WordFence or PatchStack provide in their offerings. The firewall can block attempts to exploit the vulnerability until the plugin has been updated.

The issue is further complicated by a failure in headline reports to clearly indicate the prerequisites for an exploit. For example, some exploits require a user with administrative access or a logged in user, which means that the majority of sites with only a single admin and no other users are not immediately at risk. Thus it would be safe to test the update and wait, if necessary, for a non-breaking version. When I evaluate a vulnerability disclosure now, I look to see how easy it is and under what conditions it can be exploited, because is important information to have when planning a response.

Mudding the waters, there is sometimes a hesitancy by plugin developers to clearly state in change logs when a security issue was fixed, maybe because they want to avoid bad press, but perhaps also they don’t want to alert hackers to the issue before users have updated. The problem in this type of situation is that it is not immediately clear that the site owner should hurry to apply an update. So, improving incident reports both by security researchers and plugin developers would be of benefit to end users.

What About Smaller Plugin Developers?

I’ve focused on larger plugins because smaller plugin developers may not be able to afford a code audit, but there are resources available for smaller independent developers too. For example, Patchstack has a free security program. If you are enrolled, when there is a report of a vulnerability, they will verify it and alert the developer, the developer fixes it, and then they will verify the fix and see to the responsible disclosure. This provides some infrastructure support for smaller developers for free.

Final Thoughts

A best practice is a standard is a set of guidelines that is known to produce good outcomes if followed. Sometimes there are legal or organizational requirements to follow best practices, but other times best practices are expectations by the community, which when observed, foster trust and respect. Most premium plugins now offer some type of money back guarantee and the websites have information about the team behind the product, because the community has let it be known that these practices are indications of a trustworthy business.

There are some WordPress developers who have contracted for an independent security audit, perhaps because their plugin suffered a vulnerability and they want to avoid a repeat. Others have arranged for an audit proactively because they know that there could be issues, they can afford to have one done, and they want to provide the highest quality software that they can. In either case, the WordPress community should recognize and appreciate the efforts that embrace higher standards and code quality.

Short of WordPress org requiring security audits, it falls on the community to set expectations. We do that by politely asking if a security audit has been performed and by letting developers of popular plugins know that this is something we are looking for when we’re making a purchase. I think it is reasonable to ask developers of plugins with more than a million active installs to have an independent security audit of their code, especially if there is a premium component involved. What do you think?