undefined | Better HN

0 pointsmtlynch3y ago0 comments

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

0 comments

3 comments · 1 top-level

infogulch3y ago· 2 in thread

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.

mtlynchOP3y 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.

infogulch3y 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.

j / k navigate · click thread line to collapse