Safety aspects of kirby (compared to...)

I’m currently processing a request from a customer who is part of a department of a fairly large company. Other departments are working with content management systems like Wordpress, Joomla, Drupal. As a result, there’s a certain amount of experience involved and the customer’s question is: “That’s how it was done in other departments, why should we do it differently? Why should we use the unknown kirby when we know wordpress a lot better? How secure is kirby???

I don’t have a problem finding good arguments for kirby, but the security aspect as the most important point is a bit difficult for me. The customer for example talked about wanting to know which plugins we’ll use - and pretty much referred to well-known systems like Wordpress, for which plugins apparently play a major role in security.

Where are kirby’s possible security vulnerabilities?
What should you look out for to ensure that the system is not vulnerable?
How does kirby perform compared to larger systems in this field?

Do you have any arguments for me? :wink: (I’m pretty sure that some of you are having exactly the same discussion with customers, so a small overview of good arguments will probably benefit others as well.)

It’s always a tricky thing to discuss openly on a forum, for any CMS, because it gives people who are up to no good some clues and ideas…

I will tell you two things - After reading an 8 page guide on securing a Wordpress site, and my site getting hacked, I vowed never to go anywhere near it again. The second thing is I have had sites running on Kirby professionally PEN tested and they passed with flying colors. Kirby itself is very secure, and patches are released quickly when an issue is discovered.

I would contact support directly if you have any specific technical questions. The biggest issue I am aware of is not Kirby at all, but rather peoples preference for using git for deploys - if your Git password gets compromised somehow then you leave yourself open. For this reason I prefer to deploy with rSync.

Discussing the security of a CMS is difficult. Such a system can never be 100% secure. There are too many moving parts and configurations.

Joomla and Wordpress are known for many security issues and hacks over the years, but they also have a much larger audience, which makes them more attractive for hackers.

There are a few things we can say about Kirby with caution:

We know of no hacked site in seven years.

We had about a dozen security relevant issues over the years that have been reported by security researchers and have been fixed within 2 days max. None of those issues has led to a real-world hack as far as we know. We still take such reports extremely seriously and never let them lay around even if there’s no imminent risk.

As @jimbobrjames mentioned, Kirby has been penetration tested by several large clients already and we never heard of issues from those pen tests.

We follow PHP’s core security support schedule closely and no longer support outdated PHP versions with Kirby 3 for security reasons – unlike most other systems.

Being a file-based system adds a certain layer of security to Kirby by default, by removing any potential SQL injection attacks.

Kirby installations mostly don’t rely on tons of plugins in the first place. Our plugin developer group is very well connected. We have many professional developers in there with an agency or freelancer background. There’s no guarantee that a plugin does not introduce additional security issues, but our plugin landscape looks definitely a lot less like a minefield compared to other systems.

Another beloved attack vector of a CMS is always the admin panel. Especially the login form. In our experience, poor client passwords are the worst issue here. We follow all OWASP recommendations to mitigate brute force login attacks, but short or common passwords often make it too easy to hack into a system.

Kirby has one big advantage in comparison to the other mentioned systems though, by offering the option to remove the panel entirely on the production server. Only editing content on a second–additionally protected–staging server is a very good way of avoiding any potential panel hacks.

If this is not possible you can still hide the location of the panel and API by changing their URLs. Security by obscurity is not the best method out there, but it definitely helps in this case to avoid common login or API hacks.

Additional attack vectors are forms on the site or URL-based queries and filters, which enable user input. Those are mostly out of our control and you need to make sure that they don’t offer unexpected holes. I cannot say much about them without looking closer into real-life implementations.

If you want to get close to 100% security, you can use Kirby as a static site generator (not very easy with the other systems as well) and generate plain HTML files. This will remove almost any other remaining attack vectors, but also any option to work with dynamic content.

Finally, all of the above can be ignored when the server is not configured and maintained properly. Unfortunately, we see this a lot.

You should also have a look at our security guide for additional tipps:


That is one of the reasons why I love kirby, thanks for the quick and detailed answer to my question, Bastian!

I hope that I can convince many more of my clients of the advantages of kirby. :slight_smile:

1 Like