Don’t try to sanitize input – escape output
This feels like a distinction without a difference.<p>Escaping outputs is just one way of sanitizing inputs. Sometimes it works. Sometimes it doesn&#x27;t. The author of this post even realizes that their prognostication is not general and then offers the advice to &quot;be sure to get security review&quot;...<p>At the end of the day, you need to make sure that any untrusted source is treated in a safe way by every sink and does not otherwise interfere with system specs (e.g., mangling user output). Whether that happens at line 5 (where the input is read) or line 155 (where the command is generated) doesn&#x27;t really matter. Or to be more precise, is determined by whatever design patterns the framework developer chose.<p>What matters at the end of the day is that command injection isn&#x27;t possible and the system&#x27;s specs (including UI&#x2F;UX specs) are respected.<p>Crucially, both input and output constraints are informed by the nature of both the source and the sink. Hence the existence of libraries like DomPurify and HTMLPurifier, which consider one very particular type of sink. Sometimes you will write code in domains where others haven&#x27;t written excellent libraries but where sanitization (of either input or output) is needed. E.g., embedded systems.<p>I&#x27;d replace the author&#x27;s advice with &quot;carefully specify the semantics of your sources and sinks&quot;, which is ultimately what the author&#x27;s actual advice (basically, &quot;use trusted libraries and, when not, be sure to get security review&quot;) boils down to.