Disagree.
Escaping/sanitizing on output takes extras cycles/energy that can be spared if the same process is done once upon submission.
Think more sustainable.
Escaping/sanitizing on output takes extras cycles/energy that can be spared if the same process is done once upon submission.
Think more sustainable.
It surprises me that this seem unfamiliar these days?
For most real world use cases your approach is break even at best, and often way worse.
Maybe if you also directly render some html from the backend, that would change things.
Document these assumptions in your central code standards/architecture document to get everyone aligned, and then just stick to it and enjoy a more sane codebase.
For what it's worth: if a column in your database is used in so many contexts, you could document that it's simply unsanitized. Like, I prefer having as few entries for bugs and fuckups, and knowing that the database data is always sanitized helps with that. But it's not an unbreakable, absolute sort of rule.
And I never really escape strings for SQL, as I always use prepared statements - forgetting prepared statements is an easy thing for code review to catch.
I also have a project where there is HTML stored, which is not escaped because the purpose is to directly output that HTML somewhere, and it really is supposed to be HTML.
It simply depends. But as long as it's documented, and hopefully as clear and consistent as possible.
Of course you'd need to measure this for your application, but without a performance measurement maybe it's better to default to security.