So when I was building my new site I thought I'd archive older content. According to traffic, that was a bad idea so here you go. For reference the current release of Joomla is 4.x. I always build on the current release and maintain to the latest major release update.
I'm often asked by potential clients as well as visitors to the forum, which Content Management System is the most secure: Joomla, Wordpress, or something else?
Big shout out thank you to Alan Langford for this great breakdown.
Quality hosting, keep your CMS up to date, choose solid extensions from reliable developers.
AM Graphix is proud to host on Abivia Hosting which is here in Canada, uses quality licensed extensions and offers a monthly monitoring and maintenance package designed for you.
From the now sidelined Toronto Joomla website.
Which Content Management System is the most secure: Joomla, Wordpress, or something else?
Published: Wednesday, 27 January 2016 16:11
Written by: Alan Langford
When you ask a simple question, there isn't always a simple answer. Asking which CMS is the most secure seems like a reasonable question, but it's one with no easy answer.This question is particularly vexing because it is usually posed by senior management, and it's particularly difficult to answer in a concise, non-technical way.
I have heard it in every possible variation. Is Joomla more secure than Wordpress; is Wordpress more secure than Drupal; is open source more secure than closed-source proprietary code; and so on. Here's the best non-technical answer I have:
Every web facing application will have vulnerabilities at one point or another. The most critical factor in the security of a web application isn't the application itself, but rather the security and maintenance of the software and the server environment on which it is running. The next most important factor is how the developers of the application respond to security issues. The quality of the application software is also important, but surprisingly far less critical than the first two factors.
That answer is pretty unsatisfying when someone wants to hear "X is certainly more secure than Y", but it's the best I've been able to come up with. Here's why:
The security of any software application is version dependent
Security problems are a form of software bug. The number of bugs in any body of software is higher when there's more new code in a release. Anything with a version code of 1.0.0 is guaranteed to have more bugs than something with a version code of 1.0.15. In fact, you can safely assume that version 1.0.15 fixes at least 15 serious bugs. Since security issues often trigger maintenance releases, it's safe to bet that more than half of them also fixed security problems. By the same token, one would expect that version 1.1.0 has significant new code to implement new features, and that the probability of a security issue is marginally higher, depending on the volume of new code. So the security of any application depends to some extent on the maturity of the specific version.
The security of a CMS is configuration dependent
The version number analysis gives us a hint for a piece of monolithic software, but modern content management systems are far from monolithic. The power of a good CMS is that you can easily add in functionality. But this presents a challenge. The core CMS might be rock solid in terms of security, but any system is only as secure as the weakest link, and there's no guarantee that a Wordpress plugin or Joomla extension is as stable and secure as the core. It's entirely possible to have two installations of the same version of the core, and have one secure and the other open to zero day attacks, simply because of added code.
One of the biggest risks I've seen is custom software installed into a CMS. One of the joys and pains of open source is that anyone can look at the code in search of vulnerabilities. If the person who finds a problem is ethical and reports it, open source is good. If the person uses it to develop an exploit, open source isn't so good. With custom code the source doesn't have to be distributed, and that is also good and bad. Unfortunately, my experience is that this seems to give developers permission to take security shortcuts, particularly when it comes to SQL injection attacks. If you're using custom code in your CMS, consider having a trusted professional do a security audit on the source.
Counting past issues is an unreliable indicator
Some people think that an analysis of the security track record of a project is a meaningful indicator. The hypothesis is that the more bugs get fixed, the less secure the code is/was. These people should refrain from investing in the stock market, because just like in the markets, past performance is a poor indicator of future performance. Most significantly, this metric is usually only applied to the core code. As discussed, the robustness of the core code has little to do with the robustness of a deployed site. This makes the metric useless from the outset.
This sort of statistical analysis is not only useless, but it's misguided to the point of being ridiculous. If anything, the statistic can be used to (equally wrongly) argue that projects with a higher incidence of security reports is probably more secure. If, statistically speaking, one expects one bug per 250 lines of code, and that one in fifty bugs has security implications, then statistically speaking a project that has issued one security patch for every 12,500 lines of code must be secure, and the closer they are to that ratio, the more secure they are. This is obviously absurd.
No matter how you look at it, counting security issues offers absolutely no meaningful data.
Project performance is a good indicator
While tracking the number of security fixes in a project is largely irrelevant, what is important is tracking how a project responds to security issues. It's helpful to ask these questions:
- Does the project have a clear mechanism for reporting security issues?
- What is their track record for responding to those issues?
- How well do they interact with the community to address issues?
- How easy is it for site administrators to maintain their site?
I'll use Joomla as an example here, since I've got extensive personal experience with it. Let's start with Joomla 1.0, which predates my involvement. One of the major reasons why Joomla was so popular as a fork of Mambo is because Joomla fixed some known and long outstanding security problems. So we started on the right track. Then Joomla 1.5 was introduced, and this was a code base that was rewritten from the ground up. Hundreds of thousands of lines of brand new code, with a significant risk of security problems. That risk became a reality when a zero-day vulnerability was discovered in 1.5.4. Several developers including myself rushed to fix the issue, build a new release, and push it out to the community in just a few hours. This was an achievement that made us proud, but at the same time, we realized that the heroic approach was an unreliable way to address this sort of problem.
Shortly thereafter, we created the Joomla Security Strike Force (now known more simply as the Security Team). We set up mechanisms for reporting and tracking security issues and added team members to ensure that someone could always respond to reports and evaluate them to see if there was a real issue. This is critical since there are a large number of false reports. Over time, we've joined with the larger security community so that we now issue CVE numbers for security issues; we've established communications with people responsible for security in other open source applications, and with those in the projects we depend on such as PHP. We've recently started communicating with several major hosting companies, providing advance notice of issues, and in some case offering server-level solutions that allow them to protect their entire install base.
As the 1.5 code base became increasingly robust, we found that most hacked sites were due to problems in the extensions that people put into their site. This led to the development of another team, responsible for maintaining the Joomla Vulnerable Extensions List. A policy of suspending listings of vulnerable extensions in the Joomla Extensions Directory gave third party developers a considerable incentive to improve the quality of their code. By the time 2.5 was released, site owners were capable of applying maintenance releases for both Joomla and Joomla extensions from the administrator interface.
At this point, the story is similar for all the major players in the CMS space. If you're considering a lesser known CMS, it would be wise to make sure that they meet or exceed this standard.
Server security is a critical factor
It should be clear by now that even with the best efforts of a capable team, there's still a significant chance that your website will be hacked. Maintaining the CMS and any plugins or extensions is the most important defense.
An equally significant issue is the maintenance of server software. If a host isn't keeping their application stack up to date, then a hacker may be able to exploit vulnerabilities in the host's operating system, in the web server software, in PHP, or in a number of related libraries. Often a successful exploit requires that there be vulnerabilities in both the application and the server software. If either is up to date then the exploit fails.
But what happens when all that isn't enough? If the vulnerability hasn't been reported, or if an update hasn't been applied in a timely manner, your site could get hacked. At Abivia web hosting we take a multi-faceted approach. First we have implemented firewalls that detect attack patterns and block the offenders. Then we use Apache's ModSecurity to block a large number of attack patterns, and ModSecurity is coupled to the firewall, so any hacker using these techniques is quickly blocked. Our servers run CloudLinux to achieve a high degree of isolation between accounts. We use a real time scanner to identify and disable malware, so that if a hacker manages to get past all the other defenses and uploads something with a known signature, it's removed before they can make use of it. Finally, we keep deep off-site backups for all customer accounts, so that if all other defenses fail, we can bring an account back to a state before it was hacked.
A host who keeps their systems up to date and implements extensive defenses like this is going to cost a little more than the typical "cheap" host. Personally I think a few dollars a month is a small price to pay, particularly when compared to the disruption of cleaning up a hacked site.
Another look at the answer
Let's revisit my answer to the "which CMS is more secure" question:
Every web facing application will have vulnerabilities at one point or another. The most critical factor in the security of a web application isn't the application itself, but rather the security and maintenance of the software and the server environment on which it is running. The next most important factor is how the developers of the application respond to security issues. The quality of the application software is also important, but surprisingly far less critical than the first two factors.
This boils down to a few principles:
- Use a quality, security oriented hosting company.
- Engage a professional webmaster who will maintain the CMS software.
- Take regular backups, even if your host does.
- Don't install software you don't trust into your CMS.
- Get an independent third party to audit your custom code.
Follow these, and it's very likely that your site will be safe and secure, no matter which platform you choose. Anyone who tells you that one major CMS is definitely more secure than another is likely either uninformed or has a hidden agenda.