I was confused by the "Try it examples", they all say "HTMX is working correctly", even the XSS one didn't pop up a JS alert.
Htmx does not play well with content security policy
51–60 of 64 posts
Re: Htmx does not play well with content security policy
#52Earlier quoted context omitted.
The relevant thing here is that before, CSP would protect you even if you failed to sanitize an attacker-controlled input. Bringing in htmx allows the attacker to bypass CSP, and that hasn't been documented well before. The htmx docs mention CSP in passing but don't explore the nuance that OP does.
I think that's only true if your CSP has the word 'unsafe' or '*' in it. If it doesn't, it shouldn't allow inline code or things from domains that you didn't whitelist. And that's not HTMX or CSP's fault.
>I think that's only true if your CSP has the word 'unsafe' or '*' in it.
No, that's the subtlety that a lot of people in the thread are missing. I wish OP did a better job of explaining the difference.
Imagine that you screw up and some part of your page assigns injects an attacker-controlled string without encoding properly:
So you have something like this:
{{ user_message }}
fetch('/account', { method: 'DELETE' })
The problem is that even if you keep the CSP settings secure and you add htmx into your app, the attacker can effectively achieve XSS because htmx's functionality is powerful enough that it's mostly equivalent to having arbitrary JS execution:
Re: Htmx does not play well with content security policy
#53Earlier quoted context omitted.
I mean that's the point. Reminding people of possible dangers is one very important security mission.
I think the point being made that you're replying to is that it has nothing to do with htmx. It isn't htmx that's not playing well with content security policy.
Using htmx effectively prevents using CSP for security hardening.
Re: Htmx does not play well with content security policy
#54If you allow random users to write arbitrary unsanitized HTML into other users’ pages, you have already lost , htmx or otherwise.
Besides whether it is a real security risk, this is useful information if you have to work with a security department. In particular, there are corporate environments where certain CSP settings would require approval or are simply not possible.
An article focused on "htmx requires more CSP exceptions than you might be comfortable with" would be great. This is not that article.
Re: Htmx does not play well with content security policy
#55Earlier quoted context omitted.
> you have to screw up a lot more to give the attacker complete control over the HTML. Isn't this just a XSS vulnerability?
What I mean is that imagine you have HTML like this: You might screw up and give the attacker a way to control the src attribute like: So, maybe unintentional behavior but still no xss. And if you let the attacker inject double quotes, then they can escape the attribute and do something like this: In this case, htmx would still prevent the xss because hx-disable causes htmx to ignore the hx-delete attribute in the ch…
> letting them inject extra attributes is another level, and letting them inject extra HTML elements is another level.
These are ultimately the same problem. "Letting" is the wrong word here—nobody intends to let an XSS happen. These are two scenarios I've encountered in my own work:
- You're doing custom rendering, like markdown, and the output isn't exhaustively sanitized
- You used triple braces in Handlebars (or the unescaped output syntax of your favorite templating language) and the code gets reused for something unrelated that shouldn't be using unescaped output.
"Screwing up output encoding" is an alarmingly common vulnerability. XSS is arguably one of the most (if not the most) common security vulnerability ever. That's not to say it's a problem with HTMX, but the CSP exists specifically for this reason and HTMX essentially acts as an interpreter that can run arbitrary instructions. It's definitionally a way to bypass the CSP in the face of an XSS where a traditional attack would have been otherwise blocked by the CSP.
Re: Htmx does not play well with content security policy
#56I was confused by the "Try it examples", they all say "HTMX is working correctly", even the XSS one didn't pop up a JS alert.
You can view the source to see what the HTMX code is doing
Re: Htmx does not play well with content security policy
#57Earlier quoted context omitted.
I think that's only true if your CSP has the word 'unsafe' or '*' in it. If it doesn't, it shouldn't allow inline code or things from domains that you didn't whitelist. And that's not HTMX or CSP's fault.
> I think that's only true if your CSP has the word 'unsafe' or '*' in it. No, that's the subtlety that a lot of people in the thread are missing. I wish OP did a better job of explaining the difference. Imagine that you screw up and some part of your page assigns injects an attacker-controlled string without encoding properly: So you have something like this: {{ user_message }} And the attacker can inject arbitrary…
Yeah, if HTMX is not protecting against injection of its own code, then it's absolutely at fault here. That's a huge problem.
Re: Htmx does not play well with content security policy
#58Earlier quoted context omitted.
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.
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 to // handlers.js: document.querySelector("handler-Oov1to1o").addEventListener(() => foo()) // [...] more handlers here // HTTP header content-security-policy: script-src sha256-b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4…
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.
Re: Htmx does not play well with content security policy
#59This one surprised me:
https://www.sjoerdlangkemper.nl/2024/06/26/htmx-content-secu...
But I find it scary that if `user_content` is `...` that is actually injected, as raw HTML. I would expect that the ` only has access to contents of the div it is in itself, and nothing more. But instead I understand that the HTML is injected as text (?) and then re-parsed (?).
Re: Htmx does not play well with content security policy
#60Earlier quoted context omitted.
Okay this whole article is hilarious. I still don’t want to use HTMX but now I will happily not use it, rather than angrily not use it like I do with golang.
You should try HTMX and Golang together, it's an amazingly productive way to build internal tools. Our JS framework of choice is react, but the time it takes to configure a new project in our mono-repo I could've build the whole tool with HTMX and Go. This isn't to shit on react (or our setup) they are both excellent, it's simply to highlight just how productive you can be with those tools. It's a "use responsible" s…
It’s just not for me.
HTMX fits into the middle ground: websites that are too dynamic to be made with a SSG or CMS, but not dynamic enough to be a SPA.
I don’t work on enough things that fit into that category to justify learning an entire new framework. I’d rather just write React or even use plain JS.
HTMX obviously can’t be used to build a SPA, so even if it were incredible I would still have to keep my React skills up. I’d also worry that if I build something in HTMX and it increases in scope, I’d end up rewriting it in React or maintaining a bird’s nest. It’s easy for me to tell the difference between webthings that “need to be SSG’d” and “needs React”, if I insert HTMX in the middle then I’d be second guessing if I made the right choice.
As for Golang, again I’m just not the target market for it. It took them so long to decide to add generics. For me generics are a basic feature not a nice to have. I don’t agree with the goals of the language, so there’s no point in me learning it.