Hacker News Reader

Comment by mtlynch | Hacker News Reader

Yeah, this is the dealbreaker for me with alpine.js and htmx.

And I wouldn't even say "tight CSP" as much as "standard CSP." To make alpine.js play nice with CSP, you have to allow unsafe-eval, which severely weakens your protection against XSS.

alpine.js claims to have a compatibility build with CSP, but it's not officially available, doesn't fully work, and the parts that are broken in the CSP build aren't documented.[0]

htmx works under CSP, but it opens a new vector for attackers to inject JS into your page, which effectively neuters CSP.[1]

[0] https://github.com/alpinejs/alpine/discussions/1944

[1] https://htmx.org/docs/#security

View on HN

Regarding htmx https://htmx.org/docs/#security

> htmx allows you to define logic directly in your DOM. [...] One concern with this approach, however, is security. This is especially the case if you are injecting user-created content into your site without any sort of HTML escaping discipline.

You should, of course, escape all 3rd party untrusted content that is injected into your site to prevent, among other issues, XSS attacks. Attributes starting with hx- and data-hx, as well as inline <script> tags should be filtered.

That's been SOP for web development for aeons. I'd say the rewards vastly outweigh the costs. Not a deal breaker for me.

> That's been SOP for web development for aeons. I'd say the rewards vastly outweigh the costs. Not a deal breaker for me.

Very true, but it seems from my reading of the docs that standard escaping mechanisms are not enough. i.e. you also need htmx-specific ones.

> Attributes starting with hx- and data-hx ... should be filtered.

>That's been SOP for web development for aeons. I'd say the rewards vastly outweigh the costs. Not a deal breaker for me.

You should always sanitize inputs and encode outputs, but it's difficult to get that right 100% of the time. With CSP, you have a pretty robust safety net against XSS for when you encode user-controlled data incorrectly. With htmx, you're forfeiting the safety net.

I understand that not everyone wants to use CSP because a lot of libraries break it, but to me, giving up CSP is a pretty big sacrifice.

I agree that htmx warrants an extra level of awareness as to the loss of that safety net. Especially if your encoding/escaping is done manually and is very localized (i.e. you explicitly call escaping functions from your templates or other output functions), In such cases, CSP is crucial.

That been said, that's not how XSS has typically been handled. Usually, those encoding/escaping steps are already made part of the tight Request/Response stack in the backend (e.g. as middlewares, as part of a data mapper library, or as a filter activated on the template engine or Response library). Also, this is usually a default behavior that often requires to be explicitly disabled. And as long as you don't have some "rogue" I/O processes completely outside of that pipeline, you're set.

Because of this typical setup, I tend to consider CSP a mere redundancy for XSS. If you lose that extra protection due to htmx, what you gain seems far more valuable to me.

Exactly my experience as well.

IMO, Libraries like these should state their CSP compatability upfront, Any JavaScript minimalist who are likely the target developers for these libs likely has full CSP implementation on their back-end.

Telling our library isn't compatable with CSP in a footnote seems disingenuous.

Is there a minimalist js library you would suggest that is better for security? Mithril?

I've desperately searched for one, but I can't find anything. Stimulus[0] I believe is compatible with CSP, but I've found that it's more work than just writing vanilla JS.

I've heard good things about mithril, but I've never tried it.

[0] https://stimulus.hotwired.dev/

Reply on news.ycombinator.com