4 ms·

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 tha

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.

dylan604 1y ago
> 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.
- auxiliarymoose 1y ago
  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.)
  - dylan604 1y ago
    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?
    - krapp 1y ago
      Are you one of today's 10000 on using parameterized queries and prepared statements? Unless you're doing something stupid like concatenating strings into SQL queries, there's no need to "sanitize" anything going into a database. SQL injection is a solved problem. Coming from the database and sending to the client, sure. But unless you're doing something stupid like concatenating strings into SQL statements it hasn't been necessary to "sanitize" data going into a database in ages. Edit: I didn't realize until I reread this comment that I repeated part of it twice, but I'm keeping it in because it bears repeating.
      - hoppp 1y ago
        SQL injection is solved if you use dependencies that solve it of course. Other than SQL injection there is command or log injection, file names need to be sanitized or any user uploaded content for XSS and that includes images. Any incoming JSON data should be sanitized, extra fields removed etc. Log injection is a pretty nasty sort of hack that depending on how the logs are processed can lead to XSS or Command injection
    - auxiliarymoose 1y ago
      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.
      - jfengel 1y ago
        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.
- leenify 1y ago
  As the stuff is rendered on the front-end how do you deal with tags where you do not even have the information to decide how they shall be parsed on the server? This seems rather ignorant and, in my experience, leads to security issues, such as CVE-2023-38500 or CVE-2023-23627. This is not decidable on the server-side, so you will always mess stuff like this up. Sanitization can only work properly on the client for HTML.

dylan604 1y ago

> 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.

auxiliarymoose 1y ago
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.)
- dylan604 1y ago
  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?
  - krapp 1y ago
    Are you one of today's 10000 on using parameterized queries and prepared statements? Unless you're doing something stupid like concatenating strings into SQL queries, there's no need to "sanitize" anything going into a database. SQL injection is a solved problem. Coming from the database and sending to the client, sure. But unless you're doing something stupid like concatenating strings into SQL statements it hasn't been necessary to "sanitize" data going into a database in ages. Edit: I didn't realize until I reread this comment that I repeated part of it twice, but I'm keeping it in because it bears repeating.
    - hoppp 1y ago
      SQL injection is solved if you use dependencies that solve it of course. Other than SQL injection there is command or log injection, file names need to be sanitized or any user uploaded content for XSS and that includes images. Any incoming JSON data should be sanitized, extra fields removed etc. Log injection is a pretty nasty sort of hack that depending on how the logs are processed can lead to XSS or Command injection
  - auxiliarymoose 1y ago
    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.
    - jfengel 1y ago
      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.
leenify 1y ago
As the stuff is rendered on the front-end how do you deal with tags where you do not even have the information to decide how they shall be parsed on the server? This seems rather ignorant and, in my experience, leads to security issues, such as CVE-2023-38500 or CVE-2023-23627. This is not decidable on the server-side, so you will always mess stuff like this up. Sanitization can only work properly on the client for HTML.