7 Ways to Evaluate the Security and Stability of Drupal Contrib Modules

As web developers, 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.

But sometimes, even though rules were followed and code was thoroughly tested before being released as a contributed module on Drupal.org, security issues still arise—“It’s true: perfectly secure software is a pipedream.” Therefore, it’s always a good idea to evaluate the security of a contributed module before installing it, as well as being properly informed of any security issues once it’s already installed on your site.

Here are some questions you should ask when assessing the security of a contributed module:

1. Has the module maintainer opted in to the security coverage?

Recently, a major policy change was announced on Drupal.org that allows any user to create a new project and release “stable” versions. This is important from a security standpoint because if a maintainer has not opted in to the security coverage, their module is not getting the security attention it needs to prevent major issues.

2. Have you checked for the latest security advisories and release updates?

Every Wednesday, the Drupal security team posts security advisories to Drupal.org. Starting a #security channel to automatically post updates in Slack is one of the easiest ways to monitor updates. To do this, add the Feed URLs and tell Slack to fetch and pull them into the #security channel.

Don’t have Slack? You can keep up with security releases in a number of ways:

• Subscribe to the Drupal security mailing list from your Drupal.org profile

• Add the RSS feeds for core, contrib, or public service announcements

• Bookmark this page for a list of the most recent security advisories for contributed modules

• Follow @drupalsecurity on Twitter

For a visual look, you can enable the Update manager core module and use it to check which modules have updates available:

Image

One tip to save time after getting the names of the modules is to head to the command line and run “drush upc module_name” on each one, and then run “drush updb” to install any database updates they might have.

Also be aware that significant changes can exist in major versions of a module, and may cause issues when upgrading. Security releases will be in the same branch (i.e. 7.x-2.8 to 7.x-2.9) so make sure you are not jumping from a 7.x-2.x release to a 7.x-3.x release for example.

3. Is the module the recommended version?

When browsing contributed modules on Drupal.org, module versions are organized into sections and have some color highlighting to aid in visualizing the status of all its available versions. (See: What are alpha and beta releases, and release candidates?)

“Recommended” releases are highlighted in green and “pre-stable” releases are highlighted in yellow, and download links are provided. It also explains whether or not the stable releases for the project are covered by the security advisory policy.

Image

“Unsupported” or “deprecated/obsolete” versions are not color-coded, but rather displayed with warning symbols and there is no download link actively present. These projects are no longer covered by the security advisory policy.

Use the “recommended” release of a contributed module, if one is available. In some cases, such as if the module is in its early stages of development, a “recommended” release may not be available.

If the module meets all your requirements, but it is a pre-release build version, such as Alpha or Beta, that doesn’t necessarily mean it shouldn’t be used, but extra security precautions should be taken:

• Test the module thoroughly in a non-production environment

• Check how many active sites are using the module (Ex. https://www.drupal.org/project/usage/views)

• Scan issue queues for security issues (see #5)

• Perform a code review of the module (see #6)

4. 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.

Note that unsupported and deprecated modules should not be used and alternatives should be evaluated and implemented.

Using a module not covered by the drupal security advisory policy means that you, the developer, are committing to continuous monitoring of the issue queue for security issues. One pass at the beginning is good for evaluation, but it is an ongoing commitment.

5. 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 and security 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.

6. 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 writing database queries using plain SQL instead of Drupal’s database abstraction layer are issues to look out for when scanning the code of a contributed module.

For more examples of writing secure code in Drupal and what you can look for, see https://www.drupal.org/docs/8/security.

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.

7. Are you following best practices for patching? (Patch, don’t hack!)

It’s important to follow best practices that include not “hacking” or modifying any core or contrib modules to achieve results. Instead, the best way to implement overrides is through custom modules, configuration, or contributing patches back to the projects individually. When patches are required, make sure they are documented inside each project so any future developer is aware of changes that exist when making updates.

When making a new patch, look for an issue on Drupal.org or create one if necessary. Document the issue and upload the patch to the issue. This will let others review the patch and allow it to be integrated back into the open source community.

Hacking modules isn’t just a bad idea for security - it’s just a bad idea in general. Basically, it means that you are changing the codebase directly, so any future updates (such as security updates) will wipe the custom changes, probably resulting in broken functionality. The better method is to patch the module, so after updating the module, you just reapply the patch. The security benefit of creating a patch file and contributing back on Drupal.org is that other people can review the patch and provide feedback about issues they found in your patch and catch security issues at that point. If you’re just changing the codebase, no one reviews the code except yourself, and bugs will go unnoticed.

Final Word

In closing, evaluating Drupal modules before installing them on your site is a frontline defense for security. We hope that this post shed insight on better ways to evaluate Drupal contrib modules, stay informed on security issues, and contribute back to the Drupal community. Good luck and stay secure!