Hacker News Reader

Comment by mtlynch | Hacker News Reader

I really want to switch over to htmx, as I've moved away from SPAs frameworks, and I've been much happier. SPAs have so much abstraction, and modern, vanilla JavaScript is pretty decent to work with.

The thing that keeps holding me back from htmx is that it breaks Content Security Policy (CSP), which means you lose an effective protection against XSS.[0] When I last asked the maintainer about this, the response was that this was unlikely to ever change.[1]

Alpine.js, a similar project to htmx, claims to have a CSP-compatible version,[2] but it's not actually available in any official builds.

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

[1] https://news.ycombinator.com/item?id=32158352

[2] https://alpinejs.dev/advanced/csp

[3] https://github.com/alpinejs/alpine/issues/237

View on HN

I keep seeing people talk about this, can someone create a minimum example of what this exploit would look like?

If you don't like abstraction, why would use something as abstracted and non-standard is htmx?

It's a tradeoff, and either extreme has problems.

Too much abstraction (especially leaky abstraction the way web frameworks are) makes it difficult to reason about your application.

But if you optimize for absolute minimal abstraction, then you can get stuck with code that's very repetitive where it's hard to pick apart the business logic from all the boilerplate.

htmx can work w/ a CSP, sans a few features (hx-on, event filters)

My understanding based on the docs[0] is that htmx works with CSP, but it also drastically weakens its protection, as attackers who successfully inject JS into htmx attributes gain code execution that CSP would have normally prevented.

Am I misunderstanding? If I can use htmx without sacrificing the benefits of CSP, I'd really love to use htmx.

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

I don't understand the concern. If your backend is sufficiently compromised to inject arbitrary js into sever responses then you've already lost, and I don't see how that's worse than serving a compromised App.js from the same server.

The attacker doesn't have to compromise the backend to achieve XSS.

Suppose your website displays user-generated content (like HN posts). If the attacker finds a way to bypass encoding and instead injects JS, then without CSP, the attacker gets XSS at that point. With CSP, even if the attacker can get user-generated content to render as JS, the browser will refuse to execute it.

My understanding of htmx is that the browser would still refuse to execute standard JS, but the attacker can achieve XSS by injecting htmx attributes that are effectively arbitrary JS.

If you exclude the features mentioned above by the creator, most htmx attributes seem pretty harmless from a CSP pov. Really, this is an argument for why htmx features should be built into the browser -- presumably details like this would be rooted out and resolved by browser developers before they would permit it to be included in their browser.

Alpine is a lightweight client side framework, not really at all equivalent to htmx.

I'm not sure what you mean. htmx and alpine.js are both client-side frameworks. To me, they seem to have similar goals and similar functionality.

What do you see as the difference?

The purpose of htmx is to enable the server to send fragments of markup to update the dom in response to UI events. Alpine.is is purely client side, you may not even have an application server.

Oh, I didn't realize that. Thanks!

They're neither different nor similar. In fact they work together, with Alpine managing client side reactive state (NOT app state, just interaction) and htmx managing the actual request model. That's why the htmx docs often refer to Alpine. They should be used in combination, not to displace each other.

Ah, gotcha. Thanks!

This is also comparable to how Stimulus and Turbo work together, although I found to like using Alpine in place of Stimulus with Turbo and that combination works just fine as well.

Reply on news.ycombinator.com