Hacker News Reader

Comment by kalev | Hacker News Reader

This seems to be something new. Anyone who can share why one would choose to sanitize on the front-end instead of the back-end? You might want to sanitize it before it goes over the wire, but still have to sanitize on the back-end as well as you can’t trust user input. You could sanitize it once you send it to the client, but you should not end up in a situation where you are the one sending possibly corrupted html to a client, right? I’m probably missing something

View on HN

There's a number of handy uses cases for this, but the biggest one from my point of view is another layer of defence in depth. This is something that many frontend libraries already do for you (React, Vue, etc) where you have to explicitly render unsafe HTML when you want to. Making this a standardized API simply makes it more accessible and hopefully faster. It is often the case that the backend won't know what data will be rendered and what will used in another way so it makes sense to have a sanitation step before you render what you know on the frontend to be dynamic data. Put another way, even if there is a vulnerability or two in your backend that might sum up to an injection, if you also sanitize on your frontend, you'll still keep your users safe.

There is often a need to sanitize user input that never goes to the backend at all. There are backends you don't control but from which you still need to fetch resources from and present to the client. And if this API becomes part of an JS engine, than you will be able to use it on backend as well

The front-end tends to use optimistic updates more and more, meanings the user's input is directly used, wihtout passing by the server. I guess that's one of the use cases.

Maybe you're not in control of the back end.

For example, say you were writing an app that displayed RSS feeds from different sources. You don't know what might be coming over the wire, so it would be useful to sanitize it at the point of display.

Or if you work with a CMS and you don't trust them to not allow script tags

It’s a lot easier to verify that content is safe if it’s sanitized close to where it’s used. Otherwise there’s some degree of trust involved.

Client side is required to handle inputs from server properly anyway and to use the proper API so that it doesn't interpret input as markup/code.

For server output it's optional, because preventing client side code injection is not its concern.

Reply on news.ycombinator.com