This seems like a strawman argument against example docs. HTMX just serves html, you have to sanitize your inputs somehow. You can render the HTML with any templating language that does that for you.
Of course "you have to sanitize your inputs somehow", but this example does that exactly nowhere, i.e. it is exploitable. Having the tutorial omit this problem altogether is dangerous, as not discussing it might create the impression that PostgREST somehow already handles this, or that the toy example given here does not have a glaring security vulnerability. This is particularly problematic because the reason that the docs for many other backend frameworks also don't discuss the problem is that they do in fact already handle it (usually via a built-in templating language).
Steve acknowledged the problem in a sibling comment, so hopefully the next iteration of the tutorial will address this. (Thanks!)
If you construct your DOM imperatively on the client with newElement and textContent then there is no room for XSS to sneak in, because you're never even parsing (non-static) HTML. You're inherently correct by construction! React is just a declarative wrapper around that, but all dynamic data is still structurally separate from the shape of the DOM tree.
HTMX abandons all of that, going back to "lol hope your HTML escape function is correct" (and that you use it consistently!).
You could argue that you were just moving the goalpost to serializing JSON safely… but that's a much smaller (and static!) target than escaping HTML's bespoke flavour of SGML.
The issue here is not whether we broke a few rules, or took a few liberties w/hypermedia — we did.
winks
But you can't hold a single library responsible for the behavior of a few developers unfamiliar w/ server-side template escaping. For if you do, then shouldn't we blame the whole web development ecosystem? And if the whole whole web development ecosystem is guilty, then isn't this an indictment of hypermedia's uniform interface in general?
I put it to you, Nullability: isn't this an indictment of our entire American society?
Well, you can say what you want about us, but I'm not going to sit here and listen to you badmouth the United States of America!
> But you can't hold a single library responsible for the behavior of a few developers unfamiliar w/ server-side template escaping.
"Server-side template escaping" is a much thornier issue than it seems as first, and I can certainly blame it for trying to return to a paradigm where it's a problem.
> For if you do, then shouldn't we blame the whole web development ecosystem? And if the whole whole web development ecosystem is guilty, then isn't this an indictment of hypermedia's uniform interface in general?
Yes! It's almost like SGML is a pile of garbage for safely embedding user content, and HTML doesn't exactly improve things.
> Well, you can say what you want about us, but I'm not going to sit here and listen to you badmouth the United States of America!
Oh, don't get me started on the state of the US... :)
I mean yes, but you're missing the point. "Build HTML, parse HTML into DOM, render" is inherently a much riskier proposition than "Build DOM, render", because you're relying on your escape function working correctly and matching the parser.
string templates work fine for lots of people (xss was/is a solved issue w/ escaping, but whatever) but if you want to use a DOM builder, or some sort of reactive mechanism, go head my dude
and that's leaving aside the danger of exposing so much application logic on the client side (an untrusted computing environment) inherent in SPAs, things like GraphQL, always revalidating server side (do you always remember to?) etc.
the DOM isn't useless on the server if you take that DOM that you've built up, serialize it and send it
where exactly are you expecting the attack vector to occur? between when you serialize the DOM you've built up and sent it across the wire?
> And yet, TFA is doing it wrong in an example meant to showcase the virtues of HTMX.
is it? i thought it was showing off some HTML generation thing they are working on in PostgREST. yeah, they are gonna need to get their HTML generation working w/escaping if they want people to really use it to generate HTML, like all the other HTML generation tools do...
> where exactly are you expecting the attack vector to occur? between when you serialize the DOM you've built up and sent it across the wire?
I'm expecting there to be some minor mismatch between what the serializer considers worth escaping, and what the parser considers to have some special meaning.
> the DOM isn't useless on the server if you take that DOM that you've built up, serialize it and send it
> HTMX abandons all of that, going back to "lol hope your HTML escape function is correct" (and that you use it consistently!).
You make this sound like an unsolved problem. You can use any of the frameworks, including react, in your backend to render HTML and automatically handle all of that for you.
In terms of using it consistently? I guess you could say the same about prepared statements. Yes, you have to actually use the tools and not go "lol I'm gonna just pass the HTML myself for no reason."
Because HTML escaping is more complex than it should have to be. Image parsing is also a "solved problem" (if you ignore all the parser bugs that crop up in image libraries all the time).
> I guess you could say the same about prepared statements.
Actually, prepared statements are another case of doing it right! We finally realized that safely embedding text into SQL queries is way too complex, so instead we submit prepare/parametrize the query, and transfer the values separately using a vastly simpler protocol.
