Live data from Hacker News

Htmx does not play well with content security policy

sjoerdlangkemper.nl

31–40 of 64 posts

Re: Htmx does not play well with content security policy

#31
post #17

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

Re: Htmx does not play well with content security policy

#32
post #29

Earlier quoted context omitted.

> if someone manages to inject arbitrary HTML If they can, why wouldn’t it be inline ?

Because CSP can be configured to block inline scripts.

The syntax to allow inline scripts is even "unsafe-inline" to emphasize that you are entering the danger zone.

Re: Htmx does not play well with content security policy

#34
post #14

I don't see the point of this article, it's just common sense. If you plan which parts of the DOM are replaced using HTMX, never trust user input. You'll be fine. I use Golang with HTMX and it's amazingly productive.

Not everyone's as knowledged, hence information should be shared

Re: Htmx does not play well with content security policy

#35

Checks security headers for web server hosting article and finds a F with no headers set

The headers say "Server: AmazonS3" which means it's a static site. Given that it's also a personal blog, there's not much point in CSP headers because a) it's not processing user input and b) even if an attacker achieves XSS, there's no data to steal or useful malicious actions to take on a static personal blog.

Re: Htmx does not play well with content security policy

#38
post #13

Not really news. Always sanitize user input html. No matter if you use HTMX or something else.

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.

Re: Htmx does not play well with content security policy

#39
post #14

I don't see the point of this article, it's just common sense. If you plan which parts of the DOM are replaced using HTMX, never trust user input. You'll be fine. I use Golang with HTMX and it's amazingly productive.

Not everyone's as knowledged, hence information should be shared

I think the point is that htmx is in no way special. It's the same old category of vulnerability. It's why we have execvpe. It's why we have mysql_real_escape_string_no_really_we_mean_it_this_time().

I remember a similar point being made about LLM output. Now, I'm anything but a LLM fanboy, but if you pipe unknown text into a system interface that's squarely on you.

Re: Htmx does not play well with content security policy

#40
post #21
post #17

If you allow random users to write arbitrary unsanitized HTML into other users’ pages, you have already lost , htmx or otherwise.

> If you allow random users to write arbitrary unsanitized HTML into other users’ pages, you have already lost Not really. The whole point of CSP is that, even if someone manages to inject arbitrary HTML into your page due to a bug or oversight, you can prevent injected scripts from running entirely, severely limiting what an attacker can do. I'm surprised at the amount of comments on this post that seem to be comple…

CSP is a backstop that—when configured properly and used alongside restraint in how you script—can minimize some of the worst consequences of injection.

It doesn’t wash your hands clean of the responsibility to restrict what kinds of content users can inject into served pages.

Post reply on HN