Skip to content

Kirby 3.5.7.1

Security

Always update your Kirby installation

We constantly improve the code and security of Kirby with every update. You can find the latest Kirby version and security incidents of previous Kirby releases on our security page.

Please always make sure to update to the latest version in order to fix possible issues and vulnerabilities.

However, never update a live website directly on the server. Test updates locally or on your staging server first to make sure none of your code breaks or plugins suddenly stop working. Always make sure to have a backup in place.

Please follow these instructions on how to update your installation.

How to find your current version number

Kirby's current version number is stored in /kirby/composer.json in the version field. You can also fetch the version via PHP like this:

<?= kirby()->version() ?>

Make sure to never show the version number publicly in one of your templates as that may give attackers valuable information about your site.

Secure your server

Your server's security is essential for the security of your website and data as well as Kirby's security. Please make sure that you work together with experienced system administrators and hosting partners who keep your server up to date and know how to protect it against external attacks. Don't try to setup your own server if you don't exactly know what you are doing.

Connecting with your server

Unfortunately, many cheap hosting providers still offer normal FTP accounts for their customers. This is a horrible idea. Always make sure that you only connect to your server via a secured connection (SFTP, SSH). A regular FTP connection submits your password in plain text over the network. It is very easy to get access to your password that way.

HTTPS

We can only encourage you to use a TLS certificate for your domain. Nowadays it is very easy to get a free certificate from Let's Encrypt, which even offers easy installation and updates.

Especially for the Panel, an encrypted connection between your browser and your server is very important. If you configure it yourself, make sure to use a strong configuration. Tools and guides like the Mozilla SSL Configuration Generator can help you with this. At the end, you can test your configuration at SSLLabs.

If you do not use HTTPS, your login information and all other data will be submitted in plain text to the server and can be intercepted.

Use the latest stable PHP version

Many providers unfortunately still offer very old PHP versions which are no longer maintained. Do yourself and your site a favor and always update to the latest stable PHP version. This comes with additional security and often performance benefits. If your provider does not provide a new and stable PHP version, it's a good sign to switch to a better provider.

You can check which PHP versions are still supported on the PHP website.

Passwords

Use very long passwords for the connection to your server and for your Panel logins! Try to convince your clients to use something more secure than 123456789 as well. Short passwords can be hacked by a brute-force attack within seconds. They are no longer a viable protection. Also make sure to use different passwords for different sites and tools. Never use the same password more than once. The Panel helps you with long and secure password suggestions on installation and in the user account management.

Since 3.2.3

The Panel also has a built-in brute-force protection for the Panel login. It will delay requests with invalid credentials and also block access to the Panel by IP address and by user after 10 login failures within an hour. You can change these defaults with the auth options. Please note that Kirby can't protect your SFTP/SSH accounts, also brute-force attacks are only hindered and not prevented entirely. So it's always important to use strong passwords.

Blocked folders and files

Kirby's default .htaccess file for Apache comes with a set of predefined rules to block external access to certain files and folders in order to secure them. If you run your own .htaccess file with your own set of rules, or if you use another server architecture such as Nginx, make sure to block the same files and folders with your setup.

Text files in your content folder

All text files within the content folder should not be accessible from the outside. Kirby's .htaccess file uses the following rule to achieve this:

RewriteRule ^content/(.*)\.(txt|md|mdown)$ index.php [L]

Check if this rule works in your setup by browsing to one of your content text files (e.g. http://yourdomain.com/content/site.txt). If your setup is correct, you should be redirected to the error page.

Your site folder

All your files within the site folder must be protected as well. Kirby's rule for this is:

RewriteRule ^site/(.*) index.php [L]

You can check if this block works by browsing to http://yourdomain.com/site/config/config.php. If everything is correct, you will be redirected to the error page.

Your kirby folder

Last but not least your kirby folder must be protected as well. Here's the rule:

RewriteRule ^kirby/(.*) index.php [L]

By browsing to http://yourdomain.com/kirby/bootstrap.php, you can make sure that you will be correctly redirected to the error page.

Prevent directory listings

Check if your provider/system administrator has disabled directory listings, so that the contents of your directories are not listed if accessed directly. If directory listings are enabled and you don't have access to the server configuration, add the following command in your .htaccess file:

Options -Indexes

File Permissions

Never set the file permissions on your server too wide (777). Especially on a shared hosting environment, other users could get access to important files of your site and overwrite or read them.

We are working on our own dedicated docs on secure file permissions, but you can find an excellent introduction into secure file permissions for WordPress on Smashing Magazine. Those instructions can be applied to any Kirby installation as well.

Secure data in Git repositories

.gitignore /site/accounts

When you use a public repository for your website (for example on GitHub or Bitbucket), you must make sure to not check in your account files and push them to GitHub. Kirby's Starterkit and Plainkit come with a .gitignore file, which automatically ignores the /site/accounts folder to avoid this. If you start your own repository from scratch, please double-check to add the same rule to your .gitignore file.

.gitignore /site/config/config.php

We also encourage you to exclude your config.php to avoid revealing any sensible configuration data. A good way to set your project up is to have general uncritical configuration in your main config.php and add an additional config with critical keys only on your server and your local machine, ignoring them in your .gitignore.

Kirby makes this very easy with multi-environment config files. You can add a environment-specific file by adding the domain to the filename. E.g.:

  • config.dev.mysite.com.php
  • config.mysite.com.php

Input filtering and sanitization

If you work with forms or any other kind of user-generated content on your site, you have to make sure to properly filter and sanitize any user input. Even though Kirby does not use a database system and SQL injections are therefore not possible, an attacker could still add malicious input to your text files in order to try to manipulate your site.

You can find more about Kirby's input validators in the Reference. They are a good start to check incoming user data. Additionally you should read more about PHP's input filtering functions.

Never directly add unfiltered/unvalidated user data to methods such as…

Escape content in your templates and snippets

Not all content you render in your templates or snippets can be trusted. For example, it may come from user-generated content like a registration or comment form. Or you might use content from external sources such as an API or external database. Panel editors can also be a risk, especially in larger organizations.

When you cannot fully trust the content, it is important to escape it correctly before it's sent to the browser to prevent cross-site scripting (XSS) attacks.

Reporting a Vulnerability

If you have spotted a vulnerability in Kirby's core or the Panel, please take a look at our security policy for more information on how to report the vulnerability to us.