4 ms·

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 Ja

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 https://htmx.org/docs/#security [1] https://news.ycombinator.com/item?id=32158352 https://news.ycombinator.com/item?id=32158352 [2] https://alpinejs.dev/advanced/csp https://alpinejs.dev/advanced/csp [3] https://github.com/alpinejs/alpine/issues/237 https://github.com/alpinejs/alpine/issues/237

jeremyjh 3y ago
Alpine is a lightweight client side framework, not really at all equivalent to htmx.
- mtlynch 3y ago
  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?
  - jeremyjh 3y ago
    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.
    - mtlynch 3y ago
      Oh, I didn't realize that. Thanks!
  - summarity 3y ago
    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.
    - mtlynch 3y ago
      Ah, gotcha. Thanks!
    - werdnapk 3y ago
      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.
recursivedoubts 3y ago
htmx can work w/ a CSP, sans a few features (hx-on, event filters)
- mtlynch 3y ago
  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 https://htmx.org/docs/#security
  - infogulch 3y ago
    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.
    - mtlynch 3y ago
      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.
      - infogulch 3y ago
        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.
robertoandred 3y ago
If you don't like abstraction, why would use something as abstracted and non-standard is htmx?
- mtlynch 3y ago
  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.
BeefySwain 3y ago
I keep seeing people talk about this, can someone create a minimum example of what this exploit would look like?

jeremyjh 3y ago

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

mtlynch 3y ago
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?
- jeremyjh 3y ago
  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.
  - mtlynch 3y ago
    Oh, I didn't realize that. Thanks!
- summarity 3y ago
  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.
  - mtlynch 3y ago
    Ah, gotcha. Thanks!
  - werdnapk 3y ago
    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.

recursivedoubts 3y ago

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

mtlynch 3y ago
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 https://htmx.org/docs/#security
- infogulch 3y ago
  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.
  - mtlynch 3y ago
    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.
    - infogulch 3y ago
      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.

robertoandred 3y ago

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

mtlynch 3y ago
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.

BeefySwain 3y ago

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