If you allow random users to write arbitrary unsanitized HTML into other users’ pages, you have already lost , htmx or otherwise.
Htmx does not play well with content security policy
31–40 of 64 posts
Re: Htmx does not play well with content security policy
#32Earlier 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.
Re: Htmx does not play well with content security policy
#33Re: Htmx does not play well with content security policy
#34I 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.
Re: Htmx does not play well with content security policy
#35Checks security headers for web server hosting article and finds a F with no headers set
Re: Htmx does not play well with content security policy
#36Re: Htmx does not play well with content security policy
#37Re: Htmx does not play well with content security policy
#38Not 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.
And that's not HTMX or CSP's fault.
Re: Htmx does not play well with content security policy
#39I 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 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
#40If 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…
It doesn’t wash your hands clean of the responsibility to restrict what kinds of content users can inject into served pages.