At Mediacurrent, we take website security very seriously. Drupal has some security best practices baked into its APIs that let developers create their own modules, hopefully with secure code, to contribute back to the community. You contribute back, don’t you?
But sometimes, even though rules were followed and code has been thoroughly tested before being released as a contributed module on Drupal.org, security issues can still arise. Therefore, it’s always a good idea to evaluate the security of the contributed module before installing it, as well as being properly informed of any security issues once it’s already installed on your site.
Monitoring for Security Advisories
In case you missed it, a security advisory was recently announced for the XML Sitemap module. Here is the link to the security advisory: https://www.drupal.org/node/2733537
Here is a list of the most recent security advisories for contributed modules:
https://www.drupal.org/security/contrib
How to Evaluate Contrib Module Security
Here are some questions you should ask when assessing the security of a contributed module:
1. Is the module the recommended version?
On Drupal.org, when browsing contributed modules, module versions are organized into sections and have some highlighting to aid in visualizing the status of all its available versions. Recommended releases are highlighted in green, not-recommended releases are highlighted in yellow, and unsupported or development versions are highlighted in red.
It’s always a good idea to use the recommended release of a contributed module, if one is available. In some cases, such as if the module is in it’s early stages of development, a recommended release may not be available. In most cases, a not-recommended or development version can be used, but extra care should be taken as they may have not yet been fully tested and there may be unknown (or known) security issues.
2. Is the module deprecated or unsupported?
There are a few reasons a module might be deprecated or unsupported. A module might be deprecated because it’s functionality is similar or identical to another module on Drupal.org, so it has been deprecated in favor of that other module. Another instance that would cause a module to become deprecated is when its functionality has been ported into Drupal core.
A module might be unsupported if the module’s maintainer has little or no time to provide support to issues submitted to the issue queue. If a module’s “Maintenance status” is set to “Minimally maintained” or “Seeking new maintainer,” it’s likely the module isn’t getting the support it needs to stay stable and secure. Modules can also be marked unsupported by the Drupal Security Team for security reasons.
Generally, unsupported and deprecated modules should be avoided, as they are no longer being actively maintained, meaning the code is outdated and could leave your site vulnerable due to security issues.
3. How many issues are in the issue queues?
The issue queue on a module’s project page is a great place to find out the stability of a contributed module. When bugs are discovered by other users, issues are created in the issue queue for the module on Drupal.org.
Scan the issue queue and look for any issues related to security, which should be marked as “Critical” priority. Keep in mind, the Drupal security team actively works with core and contributed maintainers to fix security issues and routinely provide public service announcements related to security issues.
4. Are you a developer? Do you see any issues in the code?
Things like not running text through the check_plain() or filter_xss() functions, passing unsanitized data into a module file via $_GET arguments, or running database queries with plain SQL and not using Drupal’s Database API are things to look at when scanning the code of a contributed module.
What better way to contribute back to the Drupal community than to help fix issues? If you see a security issue in a contributed module, report the security-related bug. If you’re sure it’s not a security-related bug, you can just report the bug in the contributed module’s issue queue and/or submit a patch to an existing issue.
BONUS: How can you stay informed of Drupal security issues?
At Mediacurrent, we use Slack for most of our internal communications. Slack provides a wide variety of integrations that speak with other platforms, such as Jira, Bitbucket, Jenkins, and yes, even Giphy. But, we also use it to stay informed of the latest security issues related to Drupal core and contributed modules.
Every Wednesday, the Drupal security team posts security advisories to Drupal.org and the Slack integration automatically posts them to our Security channel. We maintain a Google Spreadsheet of our client, so we can track and be sure to keep core and contributed modules updated across our clients. The lead developer on the client is notified of the security announcements, handles the core or contributed module updates, tests and verifies, and finally updates the spreadsheet noting the sites are running the latest, non-vulnerable code.
Don’t have Slack? You can also stay updated by signing up for the mailing lists (subscribe in your d.o profile), subscribing to the RSS feeds, or follow @drupalsecurity on Twitter.
In closing, it’s important to always evaluate the modules you’re wanting to install on your site before installing them. Hopefully this blog post gives some insight to better ways to evaluate the modules and also provides some ways to stay informed of the security issues.
Additional Resources
Best Practices for Drupal Site Security | Blog Post
Security Talks at DrupalCon New Orleans 2016 | Blog Post
How to Prepare Your Website for Drupal 8 | eBook
