@correct, it all depends, and I don’t see the problem with storing escaped data. It’s a space tradeoff I’m willing to make, but where I feel the penalty for failure is less severe. I’m pessimistic and nowhere near perfect, so I will forget now and again despite best efforts.
If you don’t allow unsafe characters, then just completely remove them from input. Done
If you do allow unsafe characters, there are two scenario’s
- you store user input verbatim, and you always remember to escape when displaying output, and you hope input cleaning works 100%.
- you store user input escaped, and you need to remember to unescape when your user is editing.
Penalty for failing in (1) - where you forget to escape, you expose your users to xss, etc.
Penalty for failing in (2) - editable has your escaped content lt; gt; amp; etc. - looks stupid, but still safe.
Performance penalty in (1) is continual escaping on every view.
Performance penalty in (2) is only escaping / unescaping when edited.
(2) isn’t perfect, but I’ll take the hit, trusting the team to get the few edit scenarios correct versus the 100’s of view scenario’s correct. I call it err’ing on the side of caution.
Is there something I’ve overlooked? What is your objection to storing escaped data?