9 ms·

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 rend

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/ https://htmx.org/essays/web-security-basics-with-htmx/

andybak 2y ago
> 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 2y ago
  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 2y ago
  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.
- deleted 2y ago
  [deleted]
the8472 2y ago
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 2y ago
  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 2y ago
    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.

andybak 2y ago

> 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 2y ago
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 2y ago
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.
deleted 2y ago
[deleted]

the8472 2y ago

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 2y ago
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 2y ago
  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.