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 keep your Kirby version up to date in order to fix possible issues and vulnerabilities.

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() ?>

Never use end-of-life versions

Whenever we find or get notified of a vulnerability, we release updates for all Kirby versions with active support and security support. Active support means that the version receives functionality updates, enhancements and bug fixes. Security support means that the version only receives security updates.

Versions that are "end of life" receive no updates whatsoever. We cannot ensure that these versions are free of vulnerabilities and security researchers generally don't review these versions for vulnerabilities either.

Versions that are marked end of life on our security page should therefore never be used in production.

Use versions without known vulnerabilities

To avoid attacks, we strongly recommend to only use Kirby versions that are not affected by known vulnerabilities listed in the incident table. If your Kirby version is newer than the one listed with "No known vulnerabilities", you are good to go.

If your version is older than that but still under active or security support, you can verify your security status by reviewing the incident table and looking for your particular version in the "Affected" column.

Switch off debug mode

Kirby’s debug mode is very handy to find issues in your installation, but it must be switched off in production!

Our debug view is exposing important system information that should not be leaked to your visitors.

How to disable debug mode in your config.

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.

Use secure connections to 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.

Use and enforce 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 that is supported by your Kirby 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.

If you cannot update to the latest stable PHP version supported by Kirby, make sure to use a PHP version that has security support at the minimum. So-called "end of life" versions receive no security updates and may be vulnerable. You should never run your site on an end-of-life version of PHP.

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

Restrict the set of executable files

Because Kirby uses PHP, your web server needs to execute PHP files with the file extension .php.

Some providers unfortunately still support alternative file extensions or even other scripting languages like Perl.

Once an executable file gets on your server (e.g. via file upload in the Panel), this file can be executed simply by accessing its URL. Because the executed script has full access to your files, such attacks can have devastating consequences.

Kirby protects against file uploads with the extensions .php*, .phar* and .pht* by default (which includes deprecated extensions like .php5). Please make sure that your web server does not execute files with any other file extension.

Block access to sensitive 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 files within the content folder should not be accessible from the outside. Kirby's .htaccess file uses the following rule to achieve this:

# block all files in the content folder from being accessed directly
RewriteRule ^content/(.*) 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:

# block all files in the site folder from being accessed directly
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:

# block direct access to Kirby and the Panel sources
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.

Your .git folder

If you use a git repo on your server, you should avoid to keep it in the document root. If you have to keep it there, you must make sure that it is not publicly accessible. Otherwise it could leak sensitive information from your repository. Here's the .htaccess rule to protect it:

# block files and folders beginning with a dot, such as .git
# except for the .well-known folder, which is used for Let's Encrypt and security.txt
RewriteRule (^|/)\.(?!well-known\/) index.php [L]

By browsing to http://yourdomain.com/.git/config, 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

Disable MIME type detection

If a file has an unknown file type, the Apache server does not attach a Content-Type header to the file response by default. Browsers then try to auto-detect the file type, which can cause vulnerabilities from malicious file uploads.

We recommend to configure your server to serve unknown file types with the harmless text/plain type. You should also disable content type sniffing to prevent browsers from detecting a different content type than intended:

# serve files as plain text if the actual content type is not known
# (hardens against attacks from malicious file uploads)
Header set Content-Type "text/plain" "expr=-z %{CONTENT_TYPE}"
Header set X-Content-Type-Options "nosniff"

Restrict 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.

Prevent logging of sensitive information

Kirby logs errors to the PHP error log by default. This allows you to debug issues without having to enable the debug mode.

However you should make sure that sensitive information like passwords is not included in logs. If you are using PHP 8.2 or newer, Kirby handles this automatically for you using PHP's SensitiveParameter feature.

On older PHP versions, we recommend to disable parameter output in your logs by setting PHP's zend.exception_ignore_args option to 1 in your php.ini. But keep in mind that this will remove all parameter values from your logs, not just sensitive ones.

Use good 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.

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.

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.:

Filter and sanitize inputs

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…

• Page::create()
• $page->update()
• $kirby->users()->create()
• $user->update()
• $file->update()

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.

How to report vulnerabilities in Kirby

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.