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: https://getkirby.com/docs/guide/security
(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.)