Hello I am considering kirby as a cms for future upgrades of old customer websites.
Going through the screencast/documentation I noticed that page fields (such as $page->title()) are never escaped (using h($page->title()) / $page->title()->html() helpers) and this could lead to potential security issues because a bad editor could easily inject javascript code in those fields. Is this by design, in order to allow html code by default?
For the moment you can manually escape field content using the escape() field method. Automatic escaping is planned for the near future.
Thanks for your answer @texnixe.
As I mostly deal with framework projects, I do actually prefer to programmatically escape output. (I use the h() helper, since the Field’s escape() virtual method call the esc() helper which in turn creates a new laminas Escaper instance for every call). My question was more related to the yt video scratch courses, while in the starterkit plain-text fields are actually (and correctly) escaped via the ->html() virtual method calls.
kind regards.
Whether escaping is needed depends on your use-case and whether your Panel users can be trusted. If you do need custom HTML in fields, the only way to allow that is to print the fields without escaping, which is why this behavior is currently the default (not escaping wouldn’t be possible with an already escaped value in our current setup).
For 3.6 we plan to implement a new feature that will hopefully allow escaping by default. Stay tuned. 
Thanks, @lukasbestle . Technically, everything but html content from rich editors must be escaped. Even src and href attributes if they contains entities (like urls with query string). ($page->url() in kirby doesn’t seem to contain entities only ascii paths)
I am actually not very fond of automatic escaping :-), because I cannot tell which is and which is not. My actual question was about the examples in the videos, where $page->title() field for instance is not escaped (while in the kits is, as it should be). Thanks anyway.
To be honest, escaping has not been an integral part in our communication until recently, so it may well be that we forgot to mention it in some places.
The reason for this was that we so far considered Panel users (who have been explicitly authorized to edit pages) as trustworthy. This approach works for many projects, but we understand that other projects require the additional protection against that attack vector.
As I wrote, we have plans to make securing your templates easier with more documentation on the topic and a feature to automatically escape fields if the developer has not already done it manually.
Until then, you can manually escape content with the field methods and helpers you have mentioned.