I have an editor that lets users add HTML that is stored in the database and rendered on a web page. Since this is untrusted input, I plan to use Microsoft.Security.Ap
Have a listen to the OWASP podcast 67 with Jeff Williams on XSS. He talks about not sanitising or encoding before storage. The primary reason is that if (when) libraries evolve in response to new vulnerabilities your data is going to be stuck back in the old version. Of course this doesn’t stop you from running any input against a whitelist at the entry point and rejecting anything outside acceptable range.
AntiXss.GetSafeHtmlFragment()
)I disagree with the selected answer for two reasons
Generally you encode at the point of output and treat any data coming from a data store as untrusted by default - after all, what if someone manages to edit your database directly or via SQL injection?
You can use the in the page directive the parameter ValidateRequest="true". In this way all the Request data is validated and if there's a validation problem you can always catch the error. It also prevents sql injection threads and others not only possible XSS.
With numeric data, you can validate integer overflow or misuse of data types with Int32.TryParse() or any other of the TryParse family (Byte.TryParse Int16.TryParse...)
No need to use any other class or additional sanitizer method.