CSP allows you to whitelist/blacklist arbitrary Javascript, and ideally you completely blacklist online js from being executed at all, such that only .js files of same domain can be invoked by your website.
This serves the role of locking down injection attacks, only your explicitly approved Javascript can be invoked.
HTMX enables invoking of logic via HTML attributes on HTML elements… which CSP can’t cover
Which means you re-open yourself to injection attacks via HTML. Attackers can inject an HTML element with HTMX attributes and no amount of CSP will stop HTMX from going “Okey doke!” And invoking whatever the attributes say to do.
This effectively shoots even a completely locked down CSP config square in the nuts, totally defeating the entire point of using it.
It’s a cute idea but what is needed is a way to pre-emptively treat HTMX as a template file that transpiles everything out so the ajax happens in a separate .js file
If we had that, then it’d be safe and secure, as the whole “htmx attributes on elements” thing would just be a templating syntax, but when transpiled it wouldn’t be supported anymore so attackers can no longer inject html as an attack vector
This demonstrates a profound misunderstanding of HTMX, and how websites in general operate. So much so that I would not hesitate to describe this as somewhere between a baldfaced lie and just malicious incompetence. You can’t “invoke logic via HTML attributes,” but you can describe it. HTMX is a client side javascript library that parses custom elements you define in your HTML and uses the data described by them to initiate AJAX calls via the fetch() or XMLHttpRequest browser APIs, which CSP explicitly covers via the connect-src directive: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/connect-src. It’s literally just a javascript library that parses HTML and uses it to parameterize AJAX calls. If HTMX were somehow able to bypass CSP, then every single piece of clientside JavaScript in the world could violate it.
Proceeds to describe how you can use HTMX to invoke logic via HTML attributes
Whatever you want to call it, trigger, invoke, whatever.
You can leverage HTML attributes to automatically cause arbitrary Javascript ajax calls to happen by extension if those attributes being present.
Trying to argue the semantics of this is stupid.
You put HTML attributes on shit, and the presence of those attributes in turn causes arbitrary Javascript client side logic to fire off purely due to the presence of those attributes.
That’s like, literally it’s entire shtick.
And any web dev who remotely understands the point of CSP and why it was created, should instantly have alarm bells going off at the concept of triggering arbitrary ajax via html attributes.
“HTMX doesn’t bypass CSP! It just (proceeds to describe the exact mechanism by which it bypasses CSP)”
It’s bonkers how many people don’t grok this, SMH.
It turns out the language you use can be semantically ambiguous or misleading if you phrase it incorrectly. Today you learned.
And any web dev who remotely understands the point of CSP and why it was created, should instantly have alarm bells going off at the concept of triggering arbitrary ajax via html attributes.
Oh, did you finally manage to fucking Google how HTMX works so you could fish for more reasons to say it’s unsafe? What you’re describing is not a particular concern to HTMX. If an attacker can inject HTML into your page (for example, through an XSS vulnerability), they could potentially set up HTMX attributes to make requests to any endpoint, including endpoints designed to collect sensitive information. But, and this is very important, this is not a unique issue to HTMX; it’s a general security concern related to XSS vulnerabilities and improper CSP configurations.
Do you know what the correct cure for that is?
PROPER CSP CONFIGURATION.
“HTMX doesn’t bypass CSP! It just (proceeds to describe the exact mechanism by which it bypasses CSP)”
Do you genuinely not understand that CSP works on the browser API level? It doesn’t check to see if your JavaScript contains reference to disallowed endpoints and then prevents it from running. I don’t know how you “think” CSP operates, but what happens is this: The browser exposes an API to allow JavaScript to make HTTP requests - specifically XMLHttpRequest and fetch(). What CSP does is tell the browser “Hey, if you get an API request via XMLHttpRequest or fetch to a disallowed endpoint, don’t fucking issue it.” That’s it. HTMX does not magically bypass the underlying CSP mechanism, because those directives operate on a level beyond HTMX’s (or any JS library’s) influence BY DESIGN. You cannot bypass if it if’s properly configured. Two very serious questions: what part of this is confusing to you? And, have you ever tested this yourself in any capacity to even see if what you’re claiming is even true? Because I have tested it and CSP will block ANY HTMX issued request that is not allowed by CSP’s connect-src directive, assuming that’s set.
I felt like I had a good understanding of both htmx and csp, but after this discussion I’m going to have to read up on both because both of you are making a logically sound argument to my mind.
I’m struggling to see how htmx is more vulnerable than say react or vue or angular, because with csp as far as I can tell I can explicitly lock down what htmx can do, despite any maliciously injected html that might try to do otherwise.
CSP allows you to whitelist/blacklist arbitrary Javascript, and ideally you completely blacklist online js from being executed at all, such that only .js files of same domain can be invoked by your website.
This serves the role of locking down injection attacks, only your explicitly approved Javascript can be invoked.
HTMX enables invoking of logic via HTML attributes on HTML elements… which CSP can’t cover
Which means you re-open yourself to injection attacks via HTML. Attackers can inject an HTML element with HTMX attributes and no amount of CSP will stop HTMX from going “Okey doke!” And invoking whatever the attributes say to do.
This effectively shoots even a completely locked down CSP config square in the nuts, totally defeating the entire point of using it.
It’s a cute idea but what is needed is a way to pre-emptively treat HTMX as a template file that transpiles everything out so the ajax happens in a separate .js file
If we had that, then it’d be safe and secure, as the whole “htmx attributes on elements” thing would just be a templating syntax, but when transpiled it wouldn’t be supported anymore so attackers can no longer inject html as an attack vector
This demonstrates a profound misunderstanding of HTMX, and how websites in general operate. So much so that I would not hesitate to describe this as somewhere between a baldfaced lie and just malicious incompetence. You can’t “invoke logic via HTML attributes,” but you can describe it. HTMX is a client side javascript library that parses custom elements you define in your HTML and uses the data described by them to initiate AJAX calls via the fetch() or XMLHttpRequest browser APIs, which CSP explicitly covers via the connect-src directive: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/connect-src. It’s literally just a javascript library that parses HTML and uses it to parameterize AJAX calls. If HTMX were somehow able to bypass CSP, then every single piece of clientside JavaScript in the world could violate it.
Oh boy a semantic argument
Whatever you want to call it, trigger, invoke, whatever.
You can leverage HTML attributes to automatically cause arbitrary Javascript ajax calls to happen by extension if those attributes being present.
Trying to argue the semantics of this is stupid.
You put HTML attributes on shit, and the presence of those attributes in turn causes arbitrary Javascript client side logic to fire off purely due to the presence of those attributes.
That’s like, literally it’s entire shtick.
And any web dev who remotely understands the point of CSP and why it was created, should instantly have alarm bells going off at the concept of triggering arbitrary ajax via html attributes.
“HTMX doesn’t bypass CSP! It just (proceeds to describe the exact mechanism by which it bypasses CSP)”
It’s bonkers how many people don’t grok this, SMH.
It turns out the language you use can be semantically ambiguous or misleading if you phrase it incorrectly. Today you learned.
Oh, did you finally manage to fucking Google how HTMX works so you could fish for more reasons to say it’s unsafe? What you’re describing is not a particular concern to HTMX. If an attacker can inject HTML into your page (for example, through an XSS vulnerability), they could potentially set up HTMX attributes to make requests to any endpoint, including endpoints designed to collect sensitive information. But, and this is very important, this is not a unique issue to HTMX; it’s a general security concern related to XSS vulnerabilities and improper CSP configurations.
Do you know what the correct cure for that is?
PROPER CSP CONFIGURATION.
Do you genuinely not understand that CSP works on the browser API level? It doesn’t check to see if your JavaScript contains reference to disallowed endpoints and then prevents it from running. I don’t know how you “think” CSP operates, but what happens is this: The browser exposes an API to allow JavaScript to make HTTP requests - specifically XMLHttpRequest and fetch(). What CSP does is tell the browser “Hey, if you get an API request via XMLHttpRequest or fetch to a disallowed endpoint, don’t fucking issue it.” That’s it. HTMX does not magically bypass the underlying CSP mechanism, because those directives operate on a level beyond HTMX’s (or any JS library’s) influence BY DESIGN. You cannot bypass if it if’s properly configured. Two very serious questions: what part of this is confusing to you? And, have you ever tested this yourself in any capacity to even see if what you’re claiming is even true? Because I have tested it and CSP will block ANY HTMX issued request that is not allowed by CSP’s connect-src directive, assuming that’s set.
I felt like I had a good understanding of both htmx and csp, but after this discussion I’m going to have to read up on both because both of you are making a logically sound argument to my mind.
I’m struggling to see how htmx is more vulnerable than say react or vue or angular, because with csp as far as I can tell I can explicitly lock down what htmx can do, despite any maliciously injected html that might try to do otherwise.
Thanks for this discussion 🙂