Whenever you use a WordPress plugin authored by someone else, you’re essentially making a big leap of faith and hoping security vulnerabilities do not exist. As a part of vetting a WordPress plugin, you should always check a WordPress plugin author takes security seriously. A tell tale sign is whether the plugin has a track record of fixing security issues in the changelog. Updating software for security issues is a natural part of life on the web.
Most WordPress plugins are released under the GPL, which is the same license that WordPress itself uses. Under the GPL terms & conditions, there is no warranty or liability for any damages caused if your website is hacked due to a security vulnerability in a WordPress plugin. Ok. I’m glad that’s out of the way.
If a security vulnerability is found in a WordPress plugin, how do you think a WordPress plugin author should deal with the situation? Fix it straight away I hear you say! But there’s more to it than that. The risk needs to be fully understood before any any corrective action is taken and the response should not be reactive.
So if you’re a WordPress plugin author, you need to ask yourself the following questions:
- How easy is it for users to report security issues?
- Am I able to fix security vulnerabilities quickly if needed?
- Do you have systems in place to push out an update to my users?
- What communication can I use to disclose security vulnerabilities?
- Am I using secure coding practices?
The remainder of this post is targeted towards WordPress plugin authors.
Reporting a Security Issue
The WordPress.org plugin handbook advises users how to responsibly report security issues with plugins hosted on the WordPress.org plugin directory. You can assume most people will never read this. And what you don’t want is someone just creating a support topic on the WordPress.org support forums simply because they do not know how to contact you directly. This simply brings more awareness to the security issue at hand and tends to increase people being hacked. So here are some simple ways you can encourage users to contact you directly.
- create a dedicated e-mail address for security
- add your e-mail address inside the source code
- ensure you have a contact form on your website (and check it works…)
- add links to your website, Twitter and Github accounts in the plugin readme and main file
Note: If a security issue is posted publicly on the WordPress.org support forums, you can bring this to the attention of a moderator to remove by adding the “modlook” tag to the topic.
Timeliness to Fix
If you’re in the WordPress plugin business, then you should know that if a serious security vulnerability (or a defect for that matter) is found in your WordPress plugin, then you may need to work through the night to fix it. Do you have the ability and commitment to drop everything and fix an issue right now?
Sometimes it is entirely appropriate to delay public disclosure of a security issue until sometime after a fix has been released. This mitigates the potential impacts of hackers using this information for exploitation before people have had a chance to update. An example of this is the WordPress 4.7.2 security release, delaying disclosure of an additional security vulnerability by 1 week to ensure the safety of millions of additional WordPress sites.
In a similar vein, it may also be wise to only partially disclose a security vulnerability to hopefully allow users enough time to mitigate before criminals learn how to exploit the security vulnerability.
You can also choose not to disclose at all (keep things a secret) however this would be ethically questionable. The WordPress.org foundation believes transparency of security issues is in the public’s best interest and should always be disclosed. Transparency on security issues is generally expected of themes and plugin authors in the WordPress ecosystem.
Communicating with Users
Once you have identified the key stakeholders at risk of the security vulnerability, you can then choose the best way to disclose the issue. Some communication mediums you may consider using include the WordPress.org support forum, Twitter, Facebook, writing a blog post, e-mail and Slack.
Depending on the severity of the security vulnerability, you may want to inform as many users as soon as possible and encourage them to upgrade to the latest plugin version.
Be aware that if you choose to host your WordPress plugin on the WordPress.org plugin directory or sell it via CodeCanyon for example, then this inevitably comes with less control over the way you can communicate with your user base.
Developers who host their plugins on the WordPress.org plugin directory are left in the dark with data about their user base. You may be interested in Freemius Insights which gives developers an opportunity to collect a large variety of data, including user e-mails, which is not available to you from the WordPress.org plugin directory.
If you’re selling a WordPress plugin from your own website using the excellent Easy Digital Downloads plugin, then you can easily export all of your customer details to a CSV file including their e-mails. They also have a handy add-on called EDD Product Updates which allows you to send customized e-mails in batches to your users with updated product download links.
The WordPress.org plugin directory automatically notifies users whenever plugin updates are made available via the WP-admin. Developers can also optionally include an upgrade notice in the plugin readme file which can help to highlight why an update is necessary. Unlike the WordPress.org plugin directory, CodeCanyon only provides and notifies buyers of updates if they register with the update system.
If you do not have an e-mail subscription list, then you’re missing out on not only a valuable asset for content marketing, but a simple way to disclose security issues to your users.
Dilemma with Software Licensing
It is common for WordPress plugins to provide a 1 year software license which provide access to plugin updates and support. It goes without saying that it is important to keep your WordPress plugins up to date to ensure your website secure. However, more often than not I see people not renewing their software licences due to the extra costs and the risk of breaking something. This creates a dilemma for plugin authors to consider whether the severity of the vulnerability warrants making updates available for free to all customers regardless if their software license has expired. A recent precedent for doing this was in Feburary 2016 by Elegant Themes. You may want to find out whether your software licensing system supports this.
The WordPress security team can push out automated security enhancements for WordPress without the site owner needing to do anything on their end, and the security update will install automatically (as long as this feature is not disabled). In special circumstances you can work with the WordPress security team to resolve security issues with plugins hosted on WordPress.org and to push out automatic updates. A recent example of this being done for a WordPress plugin is Ninja Forms in May 2016. The WP Ninjas team in this case worked with the WordPress security team to coordinate rolling out security patches to websites for older versions of their plugin.
You may want to consider doing a code review of secure coding practices as a way to reduce common programming errors that could lead to security vulnerabilities. This includes sanitizing inputs, escaping outputs, using nonces for forms and URL verification and using prepared statements for database queries. To take this a step further you could also conduct some penetration testing to help identify any potential security vulnerabilities.
As a WordPress plugin author, when a security vulnerability comes a-knocking on your door, you should not be second guessing what the right course of action is. A little bit of thinking on the ethics of security disclosure and how you might respond to different security situations is the least you can do for your customers (if you really care about them).