←back to thread

Element: setHTML() method

(developer.mozilla.org)
170 points todsacerdoti | 2 comments | 22 Oct 25 09:03 UTC | HN request time: 0.444s | source
Show context
dzogchen ◴[22 Oct 25 21:13 UTC] No.45675208[source]▶
Neat. I think once this is adopted by HTMX (or similar libraries) you don't need to sanitize on the server side anymore?
replies(1): >>45675272 #
dylan604 ◴[22 Oct 25 21:19 UTC] No.45675272[source]▶
Do you honestly feel that we will ever be in a place for the server to not need to sanitize data from the client? Really? I don't. Any suggestion to me of "not needing to sanitize data from client" will immediately have me thinking the person doing the suggesting is not very good at their job, really new, or trying to scam me.

There's no reason to not sanitize data from the client, yet every reason to sanitize it.

replies(4): >>45675347 #>>45675432 #>>45675693 #>>45676358 #
auxiliarymoose ◴[22 Oct 25 23:16 UTC] No.45676358[source]▶
If you sanitize on the server, you are making assumptions about what is safe/unsafe for your clients. It's possible to make these assumptions correctly, but that requires keeping them in sync with all clients which is hard to do correctly.

Something that's sanitized from an HTML standpoint is not necessarily sanitized for native desktop & mobile applications, client UI frameworks, etc. For example, with Cloudflare's CloudBleed security incident, malformed img tags sent by origin servers (which weren't themselves by themselves unsafe in browsers) caused their edge servers to append garbage (including miscellaneous secure data) from heap memory to some requests that got indexed by search engines.

Sanitization is always the sole responsibility of the consumer of the content to make sure it presents any inbound data safely. Sometimes the "consumer" is colocated on the server (e.g. for server rendered HTML + no native/API users) but many times it's not.

replies(1): >>45676498 #
dylan604 ◴[22 Oct 25 23:33 UTC] No.45676498[source]▶
> If you sanitize on the server, you are making assumptions about what is safe/unsafe for your clients.

No. I'm making decisions on what is safe for my server. I'm a back end guy, I don't really care about your front end code. I will never deem your front end code's requests as trustworthy. If the front end code cannot properly handle encoding, the back end code will do what it needs to do to not allow stupid string injection attacks. I don't know where your request has been. Just because you think it came from your code in the browser does not mean that was the last place it was altered before hitting the back end.

replies(1): >>45676709 #
auxiliarymoose ◴[23 Oct 25 00:07 UTC] No.45676709[source]▶
How can user input be unsafe on the server? Are you evaluating it somehow?

User-generated content shouldn't be trusted in that way (inbound requests from client, data fields authored by users, etc.)

replies(1): >>45676826 #
dylan604 ◴[23 Oct 25 00:23 UTC] No.45676826[source]▶
Is that a serious question?

INSERT INTO table (user_name) VALUES ...

Are you one of today's 10000 on server side sanitizing of user data?

replies(2): >>45676888 #>>45676944 #
1. auxiliarymoose ◴[23 Oct 25 00:44 UTC] No.45676944[source]▶
Communicating with a SQL driver by concatenating strings containing user input and then evaluating it? wat?

I'm very interested in what tech stack you are using where this is a problem.

replies(1): >>45677146 #
2. jfengel ◴[23 Oct 25 01:21 UTC] No.45677146[source]▶
People do it all the time, on any tech stack that lets you execute command strings. A lot of of early databases didn't even support things like parameterized inserts.