4 ms·

It can be a complicated and error-prone process, mainly in scenarios where you have multiple mediums that require different sanitizers. Obviously you should do

It can be a complicated and error-prone process, mainly in scenarios where you have multiple mediums that require different sanitizers. Obviously you should do it. But in such scenarios, the best practice is to sanitize as close to the place it is used as possible. I've seen terrible codebases where they tried to apply multiple layers of sanitization on user input before storing to the DB, then reverse the unneeded layers before output. Obviously this didn't work. Point being, if you can move sanitization even closer to where it is used, and that sanitization is actually provided by the standard library of the platform in question, that's a massive win.

immibis 1y ago
By "sanitise" what's really meant is usually "escape". User typed their display name as <script>. You want the screen to say their display name, which is <script>. Therefore you send <script>. That's not their display name - that's just what you write in HTML to get their display name to appear on the screen. You shouldn't store it in the database in the display_name column.
- strbean 1y ago
  Agreed. The codebase I'm thinking of was html encoding stuff before storing it, then when they needed to e.g. send an SMS, trying to remember to decode. Terrible.
dylan604 1y ago
You're making a bad assumption that client side code was the last place the submitted string was altered in the path to the server. The man in the middle might have a different idea and should always be protected against on the server where it is the last place to sanitize it.
- strbean 1y ago
  Well, you have to sanitize for the transport medium, otherwise you can't sanitize at all afterwards. But if I'm sending user content in JSON and I didn't sanitize it for insertion into HTML, what man in the middle is going to be compromised? Furthermore, how can I possibly protect an unknown intermediary without knowing what it is going to do with it? Maybe it is going to try to copy a value into a 20 char buffer, I don't know!

immibis 1y ago

By "sanitise" what's really meant is usually "escape". User typed their display name as <script>. You want the screen to say their display name, which is <script>. Therefore you send <script>. That's not their display name - that's just what you write in HTML to get their display name to appear on the screen. You shouldn't store it in the database in the display_name column.

strbean 1y ago
Agreed. The codebase I'm thinking of was html encoding stuff before storing it, then when they needed to e.g. send an SMS, trying to remember to decode. Terrible.

dylan604 1y ago

You're making a bad assumption that client side code was the last place the submitted string was altered in the path to the server. The man in the middle might have a different idea and should always be protected against on the server where it is the last place to sanitize it.

strbean 1y ago
Well, you have to sanitize for the transport medium, otherwise you can't sanitize at all afterwards. But if I'm sending user content in JSON and I didn't sanitize it for insertion into HTML, what man in the middle is going to be compromised? Furthermore, how can I possibly protect an unknown intermediary without knowing what it is going to do with it? Maybe it is going to try to copy a value into a 20 char buffer, I don't know!