>you need to understand every possible input. This is often not possible. When I talk to developers about this, I point use database storage as an example. T

>you need to understand every possible input. This is often not possible. When I talk to developers about this, I point use database storage as an example. There may be computations behind the scenes that mangle the nicely input-sanitized database contents. Concatenation with other values, string work, data from some other system. Thus, data that was sanitized upon input is now questionable for output. This is well-intentioned, but leads to a false sense of security, and sometimes mangles perfectly good input. And in some applications, for example, ones that must process data in a forensic environment, any change to the input is prohibited. Thus, the only useful way to think about this is that the contents of the database is toxic and must be sanitized on output. Simply working with the input gives the programmer no useful idea about what is in the database when it comes time to output it. Frameworks these days help significantly with providing tools to properly parameterize SQL. However, it is unlikely that they handle all the cases. Consider an example where user input from a web page is used to build a column name or table name. This isn't covered by frameworks. That needs to be carefully processed in the code. >Ultimately, "Filter outputs not inputs" is incomplete advice that kinda sorta works well for the most part in web apps. The correct advice is, again, "carefully specify the semantics of your sources and sinks". It is in fact the primary advice that should be followed. So sanitization of input is a good idea, but if output is not properly encoded, somebody else is likely to profit.