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