Last updated December 15, 2015. Created on February 4, 2010.
Edited by si635, lightweight, jonathan_hunt, brahmjeet789. Log in to edit this page.

Drupal has a very good track record in terms of security, and has an organized process for investigating, verifying, and publishing possible security problems.

Drupal's security team is constantly working with the community to address security issues as they arise. More information about this process can be found in that section of the handbook.

Members of the security team sometimes perform analyses of core or contributed project code, especially if there is a weakness that can be found by easy scanning, but in general the team does not review core or contributed code.

Anyone using Drupal should subscribe to the security mailing list (by editing your account profile) in order to automatically keep up to date with the latest security advisories of all types (see below).

Frequently asked questions:

Is open source software secure?

The short answer is that open source software is as secure or more secure (in general) than proprietary software (where visibility of the source code is tightly guarded and heavily restricted). A good summary of the relevant issues can be found in this article from IBM: The security implications of open source software. The increased security of using open source was cited as one reason the White House switched to Drupal.

How Drupal addresses common security vulnerabilities

Drupal's API and default configuration are designed to be secure when used in their default modes. Issues like injection, cross-site scripting, session management, cross-site request forgeries, and others all have standard solutions in the Drupal API. For a more detailed review of the topic please read the Drupal Security Report.

Why does Drupal have more (or fewer) security advisories than another project?

Unlike many proprietary projects owned by companies with commercial reputations and certifications at stake, community-driven open source projects like Drupal have no incentive to hide security vulnerabilities—or even possible vulnerabilities. The best interest of the community is far more important than any commercial implications of being transparent with potential security issues.

The absolute number of security advisories (especially when including contributed projects) is a number without meaning and should not be used for the purpose of comparison. Drupal has over 29,000 contributed projects that are scrutinized by their users for any potential problem, and a security advisory may be issued for a relatively minor issue. For more information read Security Risk Levels

A security advisory also indicates the discovery of a potential problem, and also that the problem is resolved already. It's extremely rare that such security holes are exploited in the wild prior to the security fix being announced in the security advisory. Thus, your most important protection is keeping Drupal up to date whenever a security advisory is issued for Drupal core or the contributed code you are using.

On live sites, what vulnerabilities have been found or exploited?

Professional security audits of Drupal sites have generally found that the vast majority of security holes (90% or more) are present in the custom theme or modules written by that site's developers. That code did not get the same public scrutiny that all code on drupal.org receives.

In addition, problems at the server level (such as using insecure protocols like FTP) are more likely to be the means of a successful attack than a vulnerability in Drupal, especially in Drupal core.

For information on how to manage security in Drupal, see the Securing Your Site section of the Drupal Administration Guide.

Looking for support? Visit the Drupal.org forums, or join #drupal-support in IRC.