A Better CMS: Part 1 - Security
We use a Content Management System (CMS) that you've probably never heard of as the foundation for our websites: ProcessWire. By contrast, many of you may have heard of the "big players" - Wordpress, Joomla and Drupal - so why don't we use one of those?
In short: Security, Flexibility and Usability. I'll be focusing on security today and covering the others in later blog posts.
This part of our "Better CMS" series focuses on security. It isn't intended to scare you senseless, but security vulnerabilities on websites do occur, and when dealing with customer data it's essential that your code is as secure as reasonably possible and that your website is maintained by a competent developer.
IT-related security threats are increasing exponentially each year. Unfortunately that's a cold, hard fact and we've seen some of these threats in real-life from cryptolocker running riot on servers (not pretty watching your files encrypt in front of your eyes) to Google listing websites as hacked (a bad advert for your company).
Personal data is big business for scammers and hackers. Collecting personal details allows them to steal people's identity, set up fake bank accounts and cause some real headaches using simple and widely-available tools and techniques, and often the source of that data is from websites. Whilst your PC may be up-to-date and protected, how sure are you about your website?
You might not store customer data on your website, but even if you have just a simple contact form then it's possible for a hacker to try and find weaknesses in your CMS - the system your website is built in - and intercept that data. Have you ever had a customer send personal details like passwords or, worse, bank account information to you via email? You'd be surprised what they'll type into the forms on your website as well.
The "Big 3"
So let's briefly look at some statistics from the "Big 3" content management systems using data from their own security advisory pages.
Security issues in 2016: 5, of which 4 mention XSS (Cross-Site Scripting) vulnerabilities. The definition of an XSS vulnerability from Webopedia states:
Once XSS has been launched, the attacker can change user settings, hijack accounts, poison cookies with malicious code, expose SSL connections, access restricted sites and even launch false advertisements.
So essentially this type of vulnerability could allow a user to inject code and gain access to data stored on a website and potentially take full control of user accounts, including website administrators.
Security issues in 2016: 5 which are marked "high-severity" - your entire website could be compromised by some of these.
Security issues in 2016: 5, ranging from "Moderately Critical" through to "Critical", including code injection and bypassing access controls.
That doesn't seem like a lot though, does it?
You might think that since your PC installs security updates automatically all the time then a few security updates per year to your website's code are no big deal. Not quite - it's your customers' data at risk, not just your own, so unprotected websites are a juicy target for attackers.
Are you sure your website is being updated, and is it being updated by someone who knows what they're doing? If you're not sure then that's a risk that you shouldn't be taking.
Even if your website's content management system is set to update itself automatically (a sensible feature on face value) this can introduce other risks. Ironically, this very feature - which was implemented to make sure Wordpress websites stay up to date and more secure - was also the one feature that could have infected millions of websites in one attack, proving that even using the most prolific CMS out there doesn't automatically mean you're safe.
Plugins - one-click functionality at low, low prices
You might have used or seen a CMS that allows you to install plugins to roll out addititional functionality to your website quickly and easily - often for free.
The danger with plugins is that they're generally written by third-party developers, not the people who created the CMS they plug into. This means each plugin could well be written by a different person with a different skill level, and you're trusting a larger number of people to have written their code securely with each plugin you install. This is why, in my opinion, plugins and modules that can be installed by the client (a major draw for customers using other systems) should instead be installed by a website developer. It can be tempting to browse through galleries of plugins, picking out neat features to add to your site, but unless you know how to read through the code and satisfy yourself that it's safe then you really should leave it to the experts.
How does this all fit in with ProcessWire?
ProcessWire has been built from the start with security in mind. The core code has been written to help sanitise the majority of data requests by way of some clever code abstraction. What this means in layman's terms is that the code which we developers use to build your website and create plugin modules is safer from the start, reducing the chances of leaving the website's database open to attackers and keeping the system safer from security vulnerabilities out of the box.
Again, ProcessWire comes to the rescue with plugin modules - each module in the Modules Directory has been manually checked before being listed for download. It's still not impossible for developers to create unsafe modules, but a lot of effort has gone into helping developers write code within ProcessWire that uses built-in functions and safety features when doing so.
A major plus point of ProcessWire is that we can actually build the majority of "standard" client websites without any additional modules as the system allows developers to implement so many features without them. There comes a point however where plugins do get you from A to B quicker than building things from scratch, and that's where we would suggest modules that are relevant to your project's requirements. There are a few go-to plugins we do use regularly when it comes to things like speed optimisation, forms and search engine optimisation, but what you tend to find with ProcessWire is that you would use less plugin modules than other content management systems to achieve the same results, so that's a lot less third-party code you're potentially exposing yourself to.
And updates? They're entirely optional. The only reason we might suggest an upgrade is to take advantage of a speed increase or a new core feature. To date, since we've been using ProcessWire from mid 2012 to March 2017 there have been zero security vulnerabilities in the core code. That's not down to luck, that's down to a system that has been architected with security at the forefront and with other developers in mind to deliver robust websites to clients.
Next time we'll be talking about flexibility to give you an idea of what ProcessWire can do for projects of any size. In the meantime, if you'd like a website security audit or want to talk about switching to ProcessWire then please get in touch.