how HTMX works and what it does inherently bypasses CSP
Well, no, not really. All HTMX really does are AJAX requests to remote resources, which are performed by interpreting attributes in HTML. You specify the type of request and the target for updating. Those requests can sometimes contain parameters, of course, but any API that accepts any kind of conditional or user generated input has to sanitize that input before doing anything meaningful with it. This requirement isn’t something particular to HTMX.
You fundamentally are invoking logic via HTML attributes, which bypasses CSP
This is not true, though. You are manipulating the DOM via HTMX, but CSP has nothing to do with dynamic content manipulation. CSP is more concerned with preventing the injection of malicious code. If what you’re referring to, however, is the possibility of someone maliciously injecting HTML with HTMX that performs some nefarious action, then I have to ask (again) why you didn’t properly sanitize user input or limit the possible connection sources in your CSP.
If you have a specific example, however, of a way in which HTMX by design violates CSP that can’t be dismissed with “you coded your website poorly,” I would love to know.
This is like someone pointing out that blowing a giant hole in the hull of your ship causes it to take on water, and you respond by asking “well why aren’t you bailing out the water with a bucket?”
You do understand why Content Security Policy exists, and what it is for… right?
“We don’t need a watertight ship hull for the voyage, just reinvent and implement a bunch of strapping young lads that 24/7 bail water out of the ship as it sails, it’s faster and more efficient than doing something crazy like building your ship to be secure and water tight.”
“Wow, these screen doors really suck. I’ve stuck them on my submarine, but they just don’t keep the water out at all. Some people are going to say that I’m a fucking moron and don’t understand the technology I use or that I’m too goddamn lazy to actually take the necessary steps to keep water out of my submarine, but I know they’re wrong and it’s the technology’s fault.”
In all seriousness, HTMX is a tool designed for a specific job. If you have an API that has either non-parameterized endpoints to hit or an endpoint that accepts a single integer value or UUID or…whatever to perform a database lookup and return stored values to be interpolated into the HTML that endpoint returns, then, great, you’ve got a lightweight tool to help do that in an SPA. If you’re using it to send complex data that will be immediately and unsafely exposed to other users, then…that’s not really what it’s for. So, I think the core issue here is that you don’t really understand the use case and are opposed to it because to use it in a way that is beyond or outside the scope of its established convention is unsafe without extra work involved to guarantee said safety. It also implies you are running a website with a content security policy that either explicitly allows the execution of unsafe inline scripts or which does not care about the sources to which a script connects, which is the only way you could realistically leverage HTMX for malicious ends. So, ultimately, the choice to not adopt comprehensive security measures is one you are free to make, but I wouldn’t exactly go around telling people about it.
If you in any way have functionality that handles anything remotely requiring security, do not use HTMX.
This goes way beyond “parameterized endpoints”.
Listen extremely closely and pray to God anyone dev with more than 2 brain cells groks how serious th8s vulnerability is:
HTMX enables arbitrary invocation of ANY api endpoint with cookies included, through html attributes, which inherently can’t be covered by Content Security Policy
This is deeply important for any web dev worth their salt to understand.
Sanitizing User input should be your LAST layer of defence against attack vectors. Not, NOT, your first and only
It’s supposed to be your “break in case of emergency” system, not your primary (and only remaining) defense layer.
HTMX enables arbitrary invocation of ANY api endpoint with cookies included, through html attributes, which inherently can’t be covered by Content Security Policy
Actually, as an even more basic question…you do know that HTMX is literally just an AJAX library, right? It doesn’t actually “do” anything via HTML attributes. The additional HTMX attributes, like hx-get, hx-post, etc. just tells HTMX where and how to make the API requests. These requests are executed by the browser’s native fetch or XMLHttpRequest APIs, depending on compatibility and implementation. Therefore, HTMX is subject to the same security constraints and policies as any other JavaScript-based operation that makes HTTP requests. Which also, by definition, means that it adheres to the Content Security Policy directives configured for that website.
In other words, an HTML button element with hx-get=“https://www.some-endpoint.com/” on it would eventually translate into
Just to be clear, are you talking about some kind of templating library that literally transpiles all the htmx logic and instead packs it into individual ajax logic in js files “per element”, such that you don’t need to serve htmx client side and instead you pre-transpile all the ajax logic out to separate files?
Cause the very start of my statements was that if we had something like that then HTMX would be fine, as a templating lib that transpiled out to html+js.
That you can CSP lockdown, because now you no longer are able to invoke arbitrary logic with html attributes, only the explicitly transpiled ajax can and all concepts of htmx have been actually removed from the final html+js you actually serve to the client.
If that is what you are talking about above, then please link me because that sounds awesome and is what HTMX outta be, and would remove all of its security issues.
If that’s not what you are talking about, and you truly dont understand the fact that you can’t compare an html element that triggers logic (which you can’t CSP block), to a script chunk that performs logic (which you can CSP block), then I think you do indeed need to go read up on and understand what the point if CSP is and why it was implemented in browsers.
The two are apples and oranges. HTML elements should not be capable of invoking logic arbitrarily, that violates a core principle of html.
Just to be clear, are you talking about some kind of templating library that literally transpiles all the htmx logic and instead packs it into individual ajax logic in js files “per element”, such that you don’t need to serve htmx client side and instead you pre-transpile all the ajax logic out to separate files?
My brother in Christ, what the fuck are you talking about “transpiling HTMX” and “serving HTMX client side?” You don’t “serve” HTMX and there’s nothing to “transpile into JavaScript.” It is JavaScript. That’s like saying you “serve React client side” and “transpile JavaScript into more JavaScript.” Jesus, I feel like I’m taking crazy pills.
Cause the very start of my statements was that if we had something like that then HTMX would be fine, as a templating lib that transpiled out to html+js.
Oh, okay, so you don’t actually know what HTMX is or how it works, then? Because HTMX (https://htmx.org/) is a JavaScript library. Like, literally just a JavaScript library. It’s like…4000 lines of JavaScript. In fact you can read the source code for it here: https://github.com/bigskysoftware/htmx/blob/master/src/htmx.js. For some…insane reason you seem to think HTMX is its own language. It’s not. It’s…just a JavaScript library. There is no other language called HTMX. There is no other mechanism or tool called HTMX. No implementation or protocol or ANYTHING else. It’s just a small JavaScript library.
invoke arbitrary logic with html attributes
Once again, HTMX enhances HTML with various attributes declaratively. It utilizes custom data attributes in HTML (like hx-get, hx-post) to specify how elements on the page should behave - essentially, how and where to fetch data or submit forms without a full page reload. This is a form of declarative programming that tells the htmx.js library (which is just doing fucking AJAX) what to do when certain events occur (e.g., a click or a form submission). The actions (like the actual requesting of data from an endpoint) are performed by the code in htmx.js.
This is a fancy way of saying “if you stick an hx-get attribute on a button, then you can just say where you want a GET request to go to and what element you want updated with the HTML returned from it and htmx.js will parse that out on page load and set an event listener for the button click to know when to initiate an AJAX request to the defined endpoint.” If you had an hx-get attribute in an element in a page and that page didn’t have the htmx.js library loaded it would do literally nothing.
And, once again, HTMX, being a JavaScript library, operates under the same security constraints as any JavaScript executed in the browser. This means that:
HTMX’s scripts themselves must be loaded from sources allowed by the script-src CSP directive.
Any dynamic requests to load content or submit data initiated by HTMX are subject to CSP’s connect-src directive.
HTMX comes with a variety of CSP options, though…
Doesn’t matter, the entire implementation principle of how HTMX works and what it does inherently bypasses CSP. There’s no getting around that.
You fundamentally are invoking logic via HTML attributes, which bypasses CSP
Well, no, not really. All HTMX really does are AJAX requests to remote resources, which are performed by interpreting attributes in HTML. You specify the type of request and the target for updating. Those requests can sometimes contain parameters, of course, but any API that accepts any kind of conditional or user generated input has to sanitize that input before doing anything meaningful with it. This requirement isn’t something particular to HTMX.
This is not true, though. You are manipulating the DOM via HTMX, but CSP has nothing to do with dynamic content manipulation. CSP is more concerned with preventing the injection of malicious code. If what you’re referring to, however, is the possibility of someone maliciously injecting HTML with HTMX that performs some nefarious action, then I have to ask (again) why you didn’t properly sanitize user input or limit the possible connection sources in your CSP.
If you have a specific example, however, of a way in which HTMX by design violates CSP that can’t be dismissed with “you coded your website poorly,” I would love to know.
This is like someone pointing out that blowing a giant hole in the hull of your ship causes it to take on water, and you respond by asking “well why aren’t you bailing out the water with a bucket?”
You do understand why Content Security Policy exists, and what it is for… right?
“We don’t need a watertight ship hull for the voyage, just reinvent and implement a bunch of strapping young lads that 24/7 bail water out of the ship as it sails, it’s faster and more efficient than doing something crazy like building your ship to be secure and water tight.”
“Wow, these screen doors really suck. I’ve stuck them on my submarine, but they just don’t keep the water out at all. Some people are going to say that I’m a fucking moron and don’t understand the technology I use or that I’m too goddamn lazy to actually take the necessary steps to keep water out of my submarine, but I know they’re wrong and it’s the technology’s fault.”
In all seriousness, HTMX is a tool designed for a specific job. If you have an API that has either non-parameterized endpoints to hit or an endpoint that accepts a single integer value or UUID or…whatever to perform a database lookup and return stored values to be interpolated into the HTML that endpoint returns, then, great, you’ve got a lightweight tool to help do that in an SPA. If you’re using it to send complex data that will be immediately and unsafely exposed to other users, then…that’s not really what it’s for. So, I think the core issue here is that you don’t really understand the use case and are opposed to it because to use it in a way that is beyond or outside the scope of its established convention is unsafe without extra work involved to guarantee said safety. It also implies you are running a website with a content security policy that either explicitly allows the execution of unsafe inline scripts or which does not care about the sources to which a script connects, which is the only way you could realistically leverage HTMX for malicious ends. So, ultimately, the choice to not adopt comprehensive security measures is one you are free to make, but I wouldn’t exactly go around telling people about it.
That’s not broad enough.
If you in any way have functionality that handles anything remotely requiring security, do not use HTMX.
This goes way beyond “parameterized endpoints”.
Listen extremely closely and pray to God anyone dev with more than 2 brain cells groks how serious th8s vulnerability is:
HTMX enables arbitrary invocation of ANY api endpoint with cookies included, through html attributes, which inherently can’t be covered by Content Security Policy
This is deeply important for any web dev worth their salt to understand.
Sanitizing User input should be your LAST layer of defence against attack vectors. Not, NOT, your first and only
It’s supposed to be your “break in case of emergency” system, not your primary (and only remaining) defense layer.
I want you to please explain how HTMX bypasses the Content Security Policy connect-src directive, or any -src directive, for that matter, assuming it is specified (which it should be). Because I’m genuinely curious why the HTMX dev team would include a section on CSP in their docs if it did literally nothing, as you say.
Actually, as an even more basic question…you do know that HTMX is literally just an AJAX library, right? It doesn’t actually “do” anything via HTML attributes. The additional HTMX attributes, like hx-get, hx-post, etc. just tells HTMX where and how to make the API requests. These requests are executed by the browser’s native fetch or XMLHttpRequest APIs, depending on compatibility and implementation. Therefore, HTMX is subject to the same security constraints and policies as any other JavaScript-based operation that makes HTTP requests. Which also, by definition, means that it adheres to the Content Security Policy directives configured for that website.
In other words, an HTML button element with hx-get=“https://www.some-endpoint.com/” on it would eventually translate into
const xhr = new XMLHttpRequest(); xhr.open("GET", "https://www.some-endpoint.com/"); xhr.send();on click.
You do understand that, right?
deleted by creator
Just to be clear, are you talking about some kind of templating library that literally transpiles all the htmx logic and instead packs it into individual ajax logic in js files “per element”, such that you don’t need to serve htmx client side and instead you pre-transpile all the ajax logic out to separate files?
Cause the very start of my statements was that if we had something like that then HTMX would be fine, as a templating lib that transpiled out to html+js.
That you can CSP lockdown, because now you no longer are able to invoke arbitrary logic with html attributes, only the explicitly transpiled ajax can and all concepts of htmx have been actually removed from the final html+js you actually serve to the client.
If that is what you are talking about above, then please link me because that sounds awesome and is what HTMX outta be, and would remove all of its security issues.
If that’s not what you are talking about, and you truly dont understand the fact that you can’t compare an html element that triggers logic (which you can’t CSP block), to a script chunk that performs logic (which you can CSP block), then I think you do indeed need to go read up on and understand what the point if CSP is and why it was implemented in browsers.
The two are apples and oranges. HTML elements should not be capable of invoking logic arbitrarily, that violates a core principle of html.
My brother in Christ, what the fuck are you talking about “transpiling HTMX” and “serving HTMX client side?” You don’t “serve” HTMX and there’s nothing to “transpile into JavaScript.” It is JavaScript. That’s like saying you “serve React client side” and “transpile JavaScript into more JavaScript.” Jesus, I feel like I’m taking crazy pills.
Oh, okay, so you don’t actually know what HTMX is or how it works, then? Because HTMX (https://htmx.org/) is a JavaScript library. Like, literally just a JavaScript library. It’s like…4000 lines of JavaScript. In fact you can read the source code for it here: https://github.com/bigskysoftware/htmx/blob/master/src/htmx.js. For some…insane reason you seem to think HTMX is its own language. It’s not. It’s…just a JavaScript library. There is no other language called HTMX. There is no other mechanism or tool called HTMX. No implementation or protocol or ANYTHING else. It’s just a small JavaScript library.
Once again, HTMX enhances HTML with various attributes declaratively. It utilizes custom data attributes in HTML (like hx-get, hx-post) to specify how elements on the page should behave - essentially, how and where to fetch data or submit forms without a full page reload. This is a form of declarative programming that tells the htmx.js library (which is just doing fucking AJAX) what to do when certain events occur (e.g., a click or a form submission). The actions (like the actual requesting of data from an endpoint) are performed by the code in htmx.js.
This is a fancy way of saying “if you stick an hx-get attribute on a button, then you can just say where you want a GET request to go to and what element you want updated with the HTML returned from it and htmx.js will parse that out on page load and set an event listener for the button click to know when to initiate an AJAX request to the defined endpoint.” If you had an hx-get attribute in an element in a page and that page didn’t have the htmx.js library loaded it would do literally nothing.
And, once again, HTMX, being a JavaScript library, operates under the same security constraints as any JavaScript executed in the browser. This means that: