this post was submitted on 03 Feb 2024
490 points (94.2% liked)
Programmer Humor
32472 readers
949 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
HTMX is great and is the only frontend development tool I don't absolutely loathe. It enables lightweight SPA development, and provides a very simple and efficient mechanism for doing HTML over the wire.
Unfortunately it also kicks Content Security Policy square in the nuts and shoots a giant hole right through your website security, so if anyone on my team brings up using it I inform them it's an instant security fail if we so much as touch it.
It's a cute idea but horribly implemented. If your website has any security requirements, do not use htmx
Edit: the fact so many people have no idea about this and are downvoting is sad. People need to learn how CSP headers work, and why inherently HTMX completely bypasses this as it currently is designed.
Can you elaborate on that? I haven't used it, but just assume if you host it on your own domain you can have it play nicely with csp, there are docs in their site about it. Where did it fall short for your use case?
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.
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 🙂
CSP works on the browser API level - all HTMX does is what you could do yourself with any AJAX: send an HTTP request to an endpoint. If the CSP disallows that endpoint, it will fail.
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.