Htmx does not play well with content security policy
sjoerdlangkemper.nl
Htmx does not play well with content security policy
1–10 of 64 posts
Re: Htmx does not play well with content security policy
#2I wonder how the HTMX creator will respond, seems valid
Re: Htmx does not play well with content security policy
#3HTMX always assumes that the incoming HTML is properly sanitized. If it isn't, the application is already vulnerable.
HTMX triggers do in fact use JavaScript eval(), which will get blocked with a CSP that does not allow it. But you can use standard JS scripts to add events. The same goes for inline CSS.
Re: Htmx does not play well with content security policy
#4I wonder how the HTMX creator will respond, seems valid
Re: Htmx does not play well with content security policy
#5I wonder how the HTMX creator will respond, seems valid
Re: Htmx does not play well with content security policy
#6Re: Htmx does not play well with content security policy
#7Not really news. Always sanitize user input html. No matter if you use HTMX or something else.
Re: Htmx does not play well with content security policy
#8Not really news. Always sanitize user input html. No matter if you use HTMX or something else.
Sure, but you should always not trust any input, even if you think it's been sanitized.
Re: Htmx does not play well with content security policy
#9So, CSP is designed to help against the case where an XSS already happened. So, a lot of this seems like valid criticism, but some parts seem wrong. The "loading malicious fragments" part looks more like the motivating case for using CSP in the first place, rather than an implication of HTMX, but correct me if I'm wrong.
The "unsafe eval" and "nonces for inline scripts" sections seem like valid criticisms of how HTMX works currently. It seems both are possible to disable using the configuration, though (meaning you could remove unsafe-eval from your CSP and htmx would still work except the disabled features).
The "hx-disable" one seems like a badly designed security feature, frankly. BUT, the code that rendered the unsanitized HTML content was not htmx (looked like an erb template), so htmx shouldn't really be blamed for that one.
Re: Htmx does not play well with content security policy
#10Earlier quoted context omitted.
https://htmx.org/essays/htmx-sucks/#xss-vulnerabilities
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" sort of tech stack though, but for a lot of things... well... it's fine. We're talking about a world where the alternative might be giving some team excel access directly to a production DB. Which is infinitely stupid x 2, but it still happens if development moves too slow.