Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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



daily reminder that any API you can use to build a DOM on the front end you can also use to build a DOM on the back-end


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.


you can build HTML however you want on the server

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.

https://intercoolerjs.org/2016/02/17/api-churn-vs-security.h...

the idea that securing hypermedia driven applications is hard is dumb, it's been done successfully for decades now


> you can build HTML however you want on the server

And you're still not reading. The DOM is useless on the server, you still need to serialize and parse it.

> the idea that securing hypermedia driven applications is hard is dumb, it's been done successfully for decades now

And yet, TFA is doing it wrong in an example meant to showcase the virtues of HTMX.


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

Exactly...?




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: