Some reasons why one might not want to use Drupal? [2/5] Drupal Acidfree Module “node titles” SQL Injection Vulnerability [2/5] Drupal Unspecified Spoofing Weakness and Cross-Site Scripting [2/5] Drupal Project Issue Tracking Module Multiple Vulnerabilities [2/5] Drupal Project Module Script Insertion Vulnerability [4/5] Drupal Comment Preview Arbitrary Code Execution [1/5] Drupal Textimage Module Security Bypass [1/5] Drupal Captcha Module Security Bypass And that’s just for the month of January. RonnieMc has pointed out before, however, that this might actually be a factor to choose Drupal as it presents job security--constantly keeping up with vulnerabilities and updates to all of your components can be a full time job.All the links above reference Secunia a reporting service that aggregates reported issues on security. By doing a few searches, you can view the Secunia security issues reported for Drupal and ExpressionEngine. Performing the above searches, you can see that ExpressionEngine has had only one security advisory over the course of 3 years. Over that same time period, Drupal has had over 80. It's easy to draw the incorrect conclusion there that ExpressionEngine therefore is more secure. Secunia specifically states "The statistics provided should NOT be used to compare the overall security of products against one another." And for good reason, what we're experiencing here is a difference in security practices. In this particular difference, Drupal reports its security vulnerabilities, while ExpressionEngine does not. At the time of initial research however, it was not clear that this was the case. With the primary developers touting the security of ExpressionEngine over Drupal, I thought perhaps EE does have much better security. So I set out to see what happens when security issues are reported.
Finding ExpressionEngine ExploitsIn one day of evaluation, I found 3 security vulnerabilities in version 1.6.2 of the core ExpressionEngine software (at that time, the latest version). That didn't bode well for my expectations of EllisLabs' reporting of issues. The vulnerabilities included a simple XSS attack, unauthorized deletion of private message files, and allowing of arbitrary code execution (dangerous enough that I e-mailed the developers directly). Unsurprisingly, none of these issues were reported to Secunia.
Running PHP on the http://demo.expressionengine.com demo installation. ExpressionEngine allows and executes image files that contain PHP code.
Drupal Approach - Announced releaseDrupal believes in an open security policy. Because all the source code is available at all times, attempting to cover-up security problems by discreetly slipping it into an update isn't viable, because all the changes between versions can be tracked. The fixing of the bug usually happens through a special security process, where the security team is notified via e-mail. The problem is fixed in the source code, then an announcement is made as quickly as possible that an update needs to be applied. This explains the 80+ vulnerabilities listed by Secunia on Drupal, because every security problem is handled in a public manner. Websites running insecure versions of modules are notified via the Update Status module, strongly encouraging administrators to update the module as soon as possible.
ExpressionEngine Approach - Quiet releaseEllisLab takes the opposite approach, instead attempting to correct security problems without publicizing their errors. In the case of the 3 vulnerabilities reported from the security review, no warning was ever issued to their clients of potential vulnerabilities. A new release was created and posted to the download area, and sites that are running the previous version of the software receive a notice that a new version has been released. After the new version was released, I finally was able to see exactly how a serious vulnerability was handled. In the ExpressionEngine changelog, the vulnerability that potentially allows total control of a site was summarized in a bullet point:
Increased security with uploaded file names to prevent Apache from overzealously parsing a file as a script.It would stand to reason then, that the phrases for "increased security" or "add additional security" truly mean "fixing a security problem". The publicly available changelog lists at least 14 enhancements of security, each one likely fixing an actual security problem. In these cases, ExpressionEngine is leading their customers into a false sense of security. Claiming a high level of security publicly while quietly fixing easily exploited bugs during development.