Why use Microsoft AntiXSS library?

You can't specify or alter the white list with the AntiXSS library, which is not strange when you think about it. The AntiXSS library by default encodes all characters that are not in the following range: 0..9a..zA..Z. This set of characters is safe (and therefore are on the white list) and there's no need in encoding them. Please note that the AntiXSS library has different lists for encoding javascript, html and url’s. Please don’t use html encode for url’s, because you’ll have a security hole in your application.

Please note that the white list on HtmlEncode works different than the white list on GetSafeHtmlFragment. With HtmlEncode you say 'please encode every character that's not on the white list', with GetSafeHtmlFragment you say 'please remove all tags and attributes that are not on the white list'.

When you're using ASP.NET 4.0 I'd advice you not to use the AntiXSS library (directly), but simply use the built in mechanisms (such as HttpUtility) to encode Html. ASP.NET 4.0 allows you to configure a HttpEncoder in the configuration file. You can write your own HttpEncoder that uses the AntiXSS library (it’s likely that a future version of the AntiXSS library will contain a HttpEncoder implementation). By doing this, your whole application (and all ASP.NET controls and custom controls) will use white list encoding instead of black list encoding.

ASP.NET 4.0 also introduces a new code block for encoded text. You can use First Name: <%: Model.FirstName %>. However, I personally find <%= HttpUtility.HtmlEncode(Model.FirstName) %> more explicit.

White lists are always more secure that blacklist - just think which will be more secure, having a list of all of the people who are not allowed to your party or only allowing in those who are. (Basically blacklists can only handle attacks which are obvious or have been used before).

The AntiXss library also includes Encode methods for things like Javascript or attributes.