In web applications that have user generated content, it is clearly
necessary to provide some ability to ‘escape’ user generated text to
avoid SQL injection, XSS, and other nasty attacks. The existing dogma
on this point seems to favor escaping text as it comes out of the
database, rather than doing it on the way in.
I’m not sure that I understand the logic behind escaping text as it
comes out of the database. This approach seems to put more load on the
processor (as an escape call is generated every time data is served),
and it seems to be more prone to detrimental errors. This is a ‘default
insecure’ system that relies on the programmer to remember to escape
fields in all their views. Failure to escape an attribute leaves you
vulnerable to malicious users and provides no warning that this is the
If the system escapes all text going into a database, then the
responsibility for security falls to one or two well defined functions
in the code (the ones that actually insert or update records), instead
of a multitude of views. This would be a ‘default secure’ system.
Typically there are more places that data is displayed then where it is
entered. Of course eventually one will want to display html from the
database, but this can be accommodated by unescaping the text as needed.
Using this approach, the programmer is required to explicitly over-ride
the defaults to get at the ‘unsafe’ data. Failure to properly unescape
code when needed will result in broken functionality, but no security
Am I missing something here?
So, for all you web application development professionals out
there…why escape text on output and not on input?