←back to thread

Element: setHTML() method

(developer.mozilla.org)
167 points todsacerdoti | 4 comments | 22 Oct 25 09:03 UTC | HN request time: 0s | 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 #
jsmith99 ◴[22 Oct 25 21:24 UTC] No.45675347[source]▶
It's arguably easier just to sanitise at display time otherwise you have problems like double escaping.
replies(1): >>45675653 #
1. bpt3 ◴[22 Oct 25 21:55 UTC] No.45675653[source]▶
Easier does not mean better, which seems to be true in this case given the many, many vulnerabilities that have been exploited over the years due to a lack of input sanitization.
replies(1): >>45675823 #
2. padjo ◴[22 Oct 25 22:12 UTC] No.45675823[source]▶
In this case easier is actually better. Sanitize a string at the point where you are going to use it. The locality makes it easy to verify that sanitation has been done correctly for the context. The alternative means you have to maintain a chain of custody for the string and ensure it is safe.
replies(1): >>45676451 #
3. dylan604 ◴[22 Oct 25 23:27 UTC] No.45676451[source]▶
if you are using it at the client, sure, but then why is the server involved? if you are sending it to the server, you need to treat it like it is always coming from a hacker with very bad intentions. i don't care where the data comes from, my server will sanitize it for its own protection. after all, just because it left "clean" from your browser does not mean it was not interfered with elsewhere upstream TLS be damned. if we've double encoded something, that's fine, it won't blow up the server. at the end of that day, that's what is most important. if some double decoding doesn't happen correctly on the client, then <shrugEmoji>
replies(1): >>45679264 #
4. padjo ◴[23 Oct 25 07:41 UTC] No.45679264{3}[source]▶
Yeah as an Irish person with an apostrophe in their name this attitude is why my name routinely gets mangled or I get told my name is invalid.

You don’t escape input. You safely store it in the database and then sanitize it at the point where you’re going to use it.