4 ms·
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 se
by 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 agoThe 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 agoIf 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.