Sounds like a restatement of Postel's robustness principle[1]. Did it go out of style to "be conservative in what you send, be liberal in what you accept" and w

Sounds like a restatement of Postel's robustness principle[1]. Did it go out of style to "be conservative in what you send, be liberal in what you accept" and we need to relearn it again? Well, perhaps it did. History has shown the dangers of not handling malformed input well. Postel's principle has received scrutiny[2] for reinforcing those mistakes by creating a mistaken belief in robustness. More recent recommendations have been to be stricter in handling of inputs[3]. But I think there is some confusion between robustness and defensiveness. "Be liberal in what you accept" may be confused with "don't sanitize your inputs" when not sanitizing is the less liberal action. Robustness means the program should not fail if it receives input it didn't expect. A program that crashes, hangs, executes unintended shell code, mangles the data, changes the thermostat, or other undefined behavior is not being robust. To prevent that from happening then data must be sanitized at input so that it can be processed without those side-effects. The examples of programs failing robustness have been because they were insufficiently defensive. The bigger issue is that robustness doesn't scale easily. You may know how your bit of code will deal with malformed data, but what about every other library you use? Or other systems you communicate with? It becomes a backstage problem, where once someone has gained access to a restricted area it's assumed they are authorized to be there. The further down the tech stack you go the less likely the code will be defensive. That puts a burden on the public-facing sanity checks to anticipate how relaxed they can be about the input. If you change the definition of output to include internal-outputs, then Postel's principle gets new life. That is, try not to program the entire system and ecosystem at once, but treat each software component as an island. Be liberal not only with the data you receive from the end-user, but also with return values from functions. Be conservative and escape not only your generated HTML, but also the SQL statements you dispatch to the backend. This is what input sanitizing is actually about, it's keeping the promise to the other parts of your program that your code isn't going to give them bad data. That's also what the linked article is saying, because the HTML being generated is itself one component in a chain of programs that includes the end-user's browser. [1] https://en.wikipedia.org/wiki/Robustness_principle https://en.wikipedia.org/wiki/Robustness_principle [2] https://programmingisterrible.com/post/42215715657/postels-principle-is-a-bad-idea https://programmingisterrible.com/post/42215715657/postels-p... [3] https://datatracker.ietf.org/doc/html/draft-iab-protocol-maintenance https://datatracker.ietf.org/doc/html/draft-iab-protocol-mai...