Back in February, I wrote an article for ITworld comparing the strengths, weaknesses, and unique features of Joomla and Drupal. But there was one important topic I did not cover in that article: security.
This was deliberate. Both of these open source content management systems (CMSs) had recently pushed out new releases, so the developers I talked with weren't as familiar with them. And within the time-and-length scope of the assignment, I wasn't able to cover everything.
But software security is important -- especially for Web 2.0-type activities, where your company is exposing some write- and perhaps content-change access to non-employees.
And no software -- or its ecosystem and the sites created using it, and the people administering and using it -- is without some security flaws or concerns.
"If you look at the total number of security issues raised -- for example, on Packet Storm, from 2005, with Drupal, there were about 470 exploits or security issues raised, about twenty this year, mostly being within contributed modules, some within Drupal core. For Joomla, there are about 1,400 since 2006, about 40 so far this year," points out Jason Hill, Co-founder, Dharmatech, a software development and technology firm that uses Drupal.
Here's what some Drupal and Joomla contributors and developers have to say about the security pros, cons, and concerns for these two popular Open-Source content management systems.
Defining CMS security
Security issues for CMSs like Drupal and Joomla fall into several main categories:
"Core code" -- the modules you get when you download/install Drupal or Joomla, as developed by the team.
Third-party extensions -- add-ons written by Drupal/Joomla developers, made available to others (either free or for a price, depending), typically through central directories
Custom per-site coding -- done by design firms and other developers (who might also be the "customer")
Admin configuration and other settings -- setting access permissions for groups, users, articles, etc.
And, of course, there's also the security aspects of the physical server and its OS, and the rest of the IT environment, but that's way outside the scope of this article.
Both the Drupal and Joomla project teams, and their associated communities, do, of course, pay strong attention to security issues.
"The Drupal community is very serious about security and there is a Security Team that includes original creator Dries Buytaert and other major contributors to the platform," says Justin Powell, who runs Twin Red Media LLC, a small boutique agency that has standardized in Drupal.
[ See also: Drupal's Dries Buytaert on Building the Next Drupal ]
The team's primary goal, says Powell, "is to identify and resolve security issues in Drupal Core and contributed modules. They provide assistance to module developers in resolving security issues and provide documentation to the community on how to write secure code to start with. The efforts of the Security Team have resulted in pretty frequent software updates to keep Drupal code secure."
Some security features and concerns reflect the two CMS's slightly differing approaches.
"Joomla is focused on basic content management and security is based on purely access control," says Christopher Justice, Chief Executive Officer, Sparksight, Inc., a full-service creative and design advertising agency. (Justice has also been a member of the Open Source Matters non-profit board of directors that manages the financial and legal aspects of the Joomla project, and a contributor to various core team discussions and strategies in the Joomla core team, the engineering hub and spoke for Joomla. And, Justice notes, he has been doing content management since the mid-1990s, and estimates he has used "about 170 or more CMSs by now.") "The group and role features of Joomla 1.6 are evolutionary but still limited to the security of content (articles). Joomla needs so much more... the new Nooku platform for creating Joomla extensions may be the answer."
By contrast, says Justice, "In Drupal, everything that exists is an object, and that object can be a variety of types, content, media, applications, application programming interfaces (APIs) and more. The security principles with Drupal are designed to integrate with third-party applications in a more flexible, modern and secure way."
Keeping core code secure
"Core code" refers to what you get when you download Joomla or download Drupal. You'll probably supplement these with third-party extensions, some code of your own, and configurations and settings, but the "core" is what the projects' main teams develop.
"Both cores are terrific and very secure, and and both core development teams have good response times to reported security flaws," says Rafael Diaz-Tushman, President and CEO of Dioscouri Design, which provides IT support and web development services for the Guggenheim Museum, Jazz at Lincoln Center, and other business and non-profits.
Who -- if anybody -- reviews core code in terms of security?
With Joomla, notes Andrew Eddie, a co-founder of the Joomla project and one of the major contributors to the code base, "We have a body called the JSST (Joomla Security Strike Team), and members of that performed a security review OF JOOMLA 1.6 before we released it. When new code comes in, the people doing the Commit reviews are always mindful of security issues. And there are some simple checks and balances to look for, like 'are they using the Joomla API?'"
Developing secure modules and creating secure sites
The core isn't the only code that needs to be secure, of course.
There are thousands of extensions -- third-party modules -- available for both Drupal and Joomla. Plus there's whatever additional code has gone into creating the site.
Most extensions and other code used to create a sign will be secure. But some won't be -- most likely because their creators coded their own security functions rather than using those in the core code.
"The vast majority of issues we see, especially with third-party modules, is not using Drupal's APIs properly, and not using the security features built into the Drupal core properly," says Jeff Eaton, Senior Architect, Lullabot Inc., a Drupal development and training shop whose Drupal sites include the Grammys, Martha Stewart, Fast Company magazine, and the MTV UK web site. "Everybody has to be on the alert for this. There are tools to do relatively simple code analysis to see if they're misusing APIs."
Of course, the same can be true of Joomla extensions and sites. It's possible for a third-party component to bypass the security checks that Joomla provides, just by writing poor code. Joomla has security features like a database class smart enough to check that when you pass data to it, the data is properly sanitized. But if you hard-code their connections to the database instead, without doing any checking or sanitizing, you're introducing vulnerabilities.
One concern for Joomla users is that third-party components for Joomla don't go through any formal testing by Joomla.
By comparison, "There's a vetting process for new contributors who want their Drupal modules hosted on Drupal.org," says Dharmatech's Hill. "They have to apply for access to the system, and it goes through reviews. to make sure it's up to Drupal coding standards. Several people will comment on the module, and then it's marked as reviewed, and your project may get accepted. For Drupal modules, the vetting process is important and significant in reducing insecure code hosted on drupal.org."
According to Lullabot's Eaton, "The Drupal security team does not proactively evaluate all of the modules -- currently around 8,000. They do monitor modules being posted, and look at bug reports and responses for the core modules and the add-ons."
Security-checking extensions "is probably where the two platforms differ the most," says Alan Langford, Abivia Inc., a web site and web application development and hosting firm that builds, hosts, and maintains web sites, the vast majority of which are Joomla-based, and has also created a number of Joomla extensions. "With Drupal, you get a limited number of extensions where it's possible to control releases and vet for security issues. With Joomla, just about anyone can write an extension. With 6000+ Joomla extensions out there, there's no way Joomla has the volunteer resources available to conduct security audits before making extensions available."
So, says Langford, "We -- the Joomla teams -- are forced into a reactive approach. The Vulnerable Extensions List (VEL) and the VEL team are responsible for handling reports of security problems in extensions developed by third parties. When a vulnerability is confirmed, the corresponding listing in JED (the Joomla Extensions Directory) is suspended, and the vulnerability is announced on the VEL."
And if it's confirmed that a Joomla extension is vulnerable, its JED listing is currently unpublished -- until the problem has been fixed. "This has proved to be a powerful incentive to have developers fix and re-release their extensions," says Langford.
But this doesn't necessarily give Drupal sites the advantage, security-wise, Langford opines. "For a given functional requirement, a Joomla site builder might be able to choose from multiple extensions that implement that functionality. It's not very likely that one would choose to build their own solution when something is available."
In the Drupal world, says Langford, "The site builder is more likely to create their own solution. This creates more 'opportunity' for coding oversights by the developer, such as not sanitizing a user-provided parameter, which in turn creates a vulnerability to attacks like SQL injection or cross-site scripting. This is a problem we all face as developers. One inadvertent slip can lead to a vulnerability. That's why a larger population of reviewers is so important -- the more eyes on the code, the higher the chances a developer will find the problem before a hacker does. I'd much rather be using one of the solutions that's widely installed, widely reviewed, and widely challenged by hackers than developed and used just on one site."
Access control is getting more granular and manageable
Given that having and using a CMS typically means your company is delegating editorial and content-uploading privileges not just to employees but often to volunteers, customers, and Internet users at large, it's essential to have an Access Control List (ACL) mechanism, to define and control how much access editors, content creators and others do -- and don't -- have. And it's helpful to have easy-to-use control of the ACL configurations.
Drupal has had granular access control over content for several versions. "One of the real strengths of Drupal is its access control functionality," says Twin Red Media's Powell. "Drupal Core provides a robust Role system that defines what type of user someone is. The Permission system then defines what that user role can do on the site. A specific user ID can also have more than one role, such as a "blogger" role combined with a "paid subscriber" role. Each role associated with the user brings with it a unique set of capabilities. There is also content output filtering to ensure that whatever is published is secure and this filtering can be tied to specific user roles."
In Joomla 1.5, granular access control used to be exclusively provided by Joomla third-party extensions. However, says Dioscouri's Diaz-Tushman, "Joomla 1.6 resolved this as one of it its primary new features. Joomla administrators now have granular control down to the article, including who can edit what, when and where. The interface, while it still leaves a little to be desired, is fully functional. And the third-party developer community has released variations on the interface, with improvements.
"Prior to Joomla 1.6, good ACL tools was one of the significant advantages of Drupal," says Abivia's Langford. "Joomla 1.5 had a basket of third party access control solutions, each with its strengths and weaknesses (mostly in terms of scope and functionality). Joomla 1.6 has introduced a powerful ACL system that easily integrates with third party extensions."
Your site doesn't get -- or stay -- secure by itself
Based on the responses of the Drupal and Joomla developers I talked with, both of these popular content management systems have the inherent security -- and now, ease of use for key security-oriented tasks -- that today's site developers and their customers need. No surprise there, given their wide adoption, and the panoply of open source and proprietary alternatives readily available. If security were a serious gotcha, they wouldn't be in play.
Equally, developing CMS sites with both Drupal and Joomla requires a reasonable knowledge of network and CMS security. Site and extension developers will get the most secure results for the least work by using the APIs and functions in the core modules rather than trying to write their own or work around them (e.g., for filtering and checking user-entered field content). Whoever is administering the site at the code level needs to be watching for security alerts, and making sure that security patches, updates and other fixes are applied in a timely, proper fashion. And whoever is configuring access permissions needs to understand what's what, and set access permissions appropriately.
The real crux of Drupal versus Joomla security, says Hill, is the severity of the exploit. "Drupal has a low number of vulnerabilities compared to Joomla, and the condition to exploit Drupal, in almost all cases, requires permissions typically granted to trusted users. Joomla, on the other hand, is more vulnerable not only because of the sheer number of exploits, but the severity, and the ability to trigger the exploit as an anonymous (unauthenticated) user."
Short answer: Don't make security the deciding factor in choosing between these two Open-Source CMSs. But don't neglect security as you design, code, deploy, administer and manage your Joomla or Drupal site, any more than you would for any web site.