Hacker News Reader

Comment by jamesgeck0 | Hacker News Reader

It's worth noting the security tradeoffs of these micro-frameworks.

HTMLX uses innerHTML/outerHTML extensively, meaning that XSS is a real concern. Any sanitation of user-generated content must happen server-side. This how traditional server-side frameworks generally work, but it's the opposite of how sanitation tends to be handled in large JS frameworks such as Angular.

https://htmx.org/docs/#security

Alpine.js requires an alternative syntax to avoid running afoul of unsafe-eval Content-Security Policy. With this more verbose syntax, there no inline expressions in templates; everything is bound to attributes in Alpine.data instead.

https://alpinejs.dev/advanced/csp

View on HN

> HTMLX uses innerHTML/outerHTML extensively, meaning that XSS is a real concern.

It's the same kind of a concern as having a user input inside HTML served from a server in the first place. And typical backend frameworks people would use with HTMX are already good at mitigating XSS inside served HTML.

> Any sanitation of user-generated content must happen server-side.

Um, yes? You should treat every request to hit the backend as a potential attack, otherwise you're going to have a _really_ bad time at some point.

> it's the opposite of how sanitation tends to be handled in large JS frameworks such as Angular.

But they still do server side input validation, right? Otherwise, that would be a security concern.

The thing about server side input validation is that if you miss something, that exploit is stored in your database. Mitigating issues you missed thus requires a backfill, which may not be scalable.

So instead you sanitize any user input just before every place it’s processed. Escaped in SQL, escaped on the frontend, escaped in email mailers, etc. This philosophy means that that you can’t use things like innerHTML on the frontend at all because the server output might contain XSS, and frontend frameworks don’t escape content added to the page via direct DOM manipulation.

> Mitigating issues you missed thus requires a backfill, which may not be scalable.

My understanding of this is that you leave data that is effectively an exploit in your database, and rely on the rigor of everyone using that data to validate it correctly? Have you had to do this in real life - can you provide an example?

I guess I've seen something like "<b>This is bold</b>" rendered after someone has fixed a bug, but I've also seen that rendered as bold text because it wasn't fixed everywhere (which is terrifying to me, knowingly not fixing malicious data).

Reply on news.ycombinator.com