4 ms·

Warning: Libraries like this don't work well with tight CSP policies. See. https://alpinejs.dev/advanced/csp https://alpinejs.dev/advanced/csp

mtlynch 4y ago
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 https://github.com/alpinejs/alpine/discussions/1944 [1] https://htmx.org/docs/#security https://htmx.org/docs/#security
- canadiantim 4y ago
  Is there a minimalist js library you would suggest that is better for security? Mithril?
  - mtlynch 4y ago
    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/ https://stimulus.hotwired.dev/
- mekoka 4y ago
  Regarding htmx https://htmx.org/docs/#security 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.
  - mtlynch 4y ago
    >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.
    - mekoka 4y ago
      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.
  - jgalt212 4y ago
    > 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.
- Abishek_Muthian 4y ago
  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.
jsjohnst 4y ago
I’d argue the “good” route shown as an example should be the “default” way you use it. The alternative is arguably worse in most ways imho. Edit: not used their Alpine or Alpine-CSP, just commenting on the example syntax in the link shared by GP.
toastal 4y ago
Similar arguments apply to all CSS-in-JS approaches to. I've made sure all projects were CSS-in-CSS moving forward.
- toastal 4y ago
  approaches too*

mtlynch 4y ago

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 https://github.com/alpinejs/alpine/discussions/1944 [1] https://htmx.org/docs/#security https://htmx.org/docs/#security

canadiantim 4y ago
Is there a minimalist js library you would suggest that is better for security? Mithril?
- mtlynch 4y ago
  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/ https://stimulus.hotwired.dev/
mekoka 4y ago
Regarding htmx https://htmx.org/docs/#security 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.
- mtlynch 4y ago
  >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.
  - mekoka 4y ago
    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.
- jgalt212 4y ago
  > 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.
Abishek_Muthian 4y ago
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.

jsjohnst 4y ago

I’d argue the “good” route shown as an example should be the “default” way you use it. The alternative is arguably worse in most ways imho. Edit: not used their Alpine or Alpine-CSP, just commenting on the example syntax in the link shared by GP.

toastal 4y ago

Similar arguments apply to all CSS-in-JS approaches to. I've made sure all projects were CSS-in-CSS moving forward.

toastal 4y ago
approaches too*