[iamkonstantin]

it’s unclear what point the post is trying to make. The outlined behaviour is not specific to HTMx per-se. These are security considerations for all server rendered pages.

The “basic” golden rules:

- Only call routes you control

- Always use an auto-escaping template engine

- Only serve user-generated content inside HTML tags

- If you have authentication cookies, set them with Secure, HttpOnly, and SameSite=Lax

https://htmx.org/essays/web-security-basics-with-htmx/

[the8472]

The point of CSP is to lock down your site so that any content (buggy or malicious) can't do damage.

This requires templating engines to separate styles, scripts and event handlers from the html.

> These are security considerations for all server rendered pages.

That's not true. With the right CSP and sandbox rules content can be made inert without sanitizing.

Sanitizing is still a good idea of course, but a rendering engine that is designed with CSP in mind will provide more layers of defense.

[iamkonstantin]

What is a rendering engine with CSP in mind?

The server can, at best, set the correct CSP header. It’s a validation performed entirely in the browser. Even the best intended rendering from the server can’t prevent CSP violation attempts when the client is executing some kind of script. That’s why even frameworks like Vue and React need a correctly configured CSP.

[the8472]

Rewrite the inline styles/scripts at build times to separate files, generate the appropriate script/style elements, compute the appropriate CSP directive.

The renderer could rewrite

   <div onclick="foo()">

to

   <div id="handler-Oov1to1o">
   <script integrity="sha256-b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c" src="generated-content/handlers.js"></src>

   // handlers.js:

   document.querySelector("handler-Oov1to1o").addEventListener(() => foo())
   // [...] more handlers here

   // HTTP header

   content-security-policy: script-src sha256-b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c <...>;
   

(the boilerplate can be amortized over many such handlers)

Or at least use 'unsafe-hashes' and compute the hashes for onclick handlers and the like and include those in the CSP.

Separation of style/scripts/content has been encouraged for a long time, I don't know why people are walking it back. But if they insist then templates could also be structured more like a multipart document where those aspects sit in separate parts of the document.

As long as you do any of those when the template renderers are compiled then only scripts whitelisted at buildtime will be executed and scripts injected by dynamic content will get blocked.

[iamkonstantin]

Thank you for clarifying, now I understand what you mean. I think we’re on the same page! I like separating assets as they can also have a very different lifecycle than the structure / content of a page.

[andybak]

> These are security considerations for all server rendered pages

Well - "server rendered" to my ears primarily means plain html generated on the server using Perl, Python, PHP, CGI or whatever. I presume you mean "server rendered with some client-side code to handle injecting into the current DOM.

Am I just too old-school or does using "server rendered" to mean fairly specific things seem strange?

[isodev]

You're correct. Server-rendered pages may also have some client-side interactivity using, for example, JavaScript/AJAX.... It doesn't need to be a fancy framework like htmx, but one needs to be mindful about user input and remote content either way. The same "techniques" for securing a web page remain in effect.

[vidarh]

It doesn't matter how it's rendered or where it's rendered. If it lets user A put unescaped/filtered/sanitised data on user B's pages, it's a security issue, no matter how the page was rendered. It's one that can be mitigated in various ways, but it's important to take into account.