Anti-Cross Site Scripting Library

AntiXSS helps you to protect your current applications from cross-site scripting attacks, at the same time helping you to protect your legacy application with its Security Runtime Engine. Working with customer and partner feedback, AntiXSS incorporates radically and innovatively rethought features, offering you a newer, more powerful weapon against the often employed cross-site scripting (XSS) attack. AntiXSS gives you:

  • Improved Performance. AntiXSS has been completely rewritten with performance in mind, and yet retains the fundamental protection from XSS attacks that you have come to rely on for your applications.
  • Secure Globalization. The web is a global market place, and cross-site scripting is a global issue. An attack can be coded anywhere, and Anti-XSS now protects against XSS attacks coded in dozens of languages.
  • Standards Compliance. AntiXSS is written to comply with modern web standards. You can protect your web application without adversely affecting its UI.

A Solid Foundation for Developers

Anti-XSS is a powerful tool in the Microsoft toolbox that mitigates XSS risks. Additionally, Anti-XSS provides a consistent level of security allowing you to focus on solving business problems and not on security problems.

No matter your development experience level, its online documentation, example code, unit tests, and calling schemes make it easy for you to know how to protect your applications from XSS attacks. Additionally, a performance data sheet helps you plan your secure deployment with full knowledge of how AntiXSS will likely perform in your environment.


Channel9 Screencast Anti-XSS Library v3.1: Find, Fix, and Verify Errors

Vineet Batta & Anil Revuru (RV) talk about the release of the new version of the Anti-XSS library and explain the new features and benefits found on version 3.0.

Anti-XSS 3.0 Released

Anil Revuru (RV) gives a demonstration of the new features on the Anti-XSS Library v3.1 including HTML Sanitization which provides new methods to the Anti-XSS class to strip malicious characters or scripts off of HTML and returns safe HTML.

Webcast Managing Cross-Site Scripting Using CAT.NET and AntiXSS

In this webcast, we provide an overview of the tools designed for discovery and mitigation of cross-site scripting vulnerabilities in Microsoft .NET applications.

Frequently Asked Questions

Q. I am currently using the .NET Framework System.Web.HttpUtility.HtmlEncode and other encoding methods in this class to encode output. Does the Microsoft Anti-Cross Site Scripting Library address a vulnerability in these methods? Are the encoding methods provided in the .NET Framework safe to use?

A. The encoding methods native to the .NET Framework are safe to use and no vulnerability is being addressed by this release of the Microsoft Anti-Cross Site Scripting Library. The Microsoft Anti-Cross Site Scripting Library differs from these methods in that it uses the principle of inclusions technique, which first defines a set of valid characters so that anything outside that set is automatically encoded.

Q. If I encode un-trusted input with System.Web.HttpUtility.HtmlEncode will this avoid Cross Site Scripting in all scenarios?

A. No, this is because System.Web.HttpUtility.HtmlEncode take a different approach than the one used by the Microsoft Anti-Cross Site Scripting Library (principle of inclusions) and encode only certain characters designated as potentially dangerous such as <, >, &, ' and characters with ASCII decimal values of 160-255. Anti-XSS library encodes character outside the range of an extensive whitelist which includes characters through A to Z, 0 to 9, space and other Unicode characters. Thus Anti-XSS Library can protect applications from cross site scripting attacks in most of the scenarios.

Q. When I use Microsoft.Security.Application.AntiXss.UrlEncode to encode the input I get back When I place this into an A tag (i.e <a href=''>Click me</a>), the link doesn't work. What's happening?

A. The UrlEncode method is meant to be used to encode un-trusted data used in the context of URLs (for instance, if the un-trusted data is being used as a value within a query string) and not the URL itself. If the URL itself is the un-trusted input, then you could perform input validation using regular expressions to validate the URL.

Q. Can I encode the input and store it in a data store?
A. No, encoding should be performed just before the input is sent to the browser and if input is encoded using HtmlEncode then it cannot be used in other contexts such as JavaScript or Url etc.

Q. Is there a discussion forum for this library?

A. Yes, please visit

Q.The ASP.NET server controls (like TextBox, BulletedList, and so on) use the existing encoding methods in the .NET Framework. Why should I use the methods in the Anti-Cross Site Scripting Library when my server controls use the methods from the .NET Framework? Is there any way to force the server controls to use the methods from the Anti-Cross Site Scripting Library?

A. There currently is no way to force existing server controls to use the Anti-Cross Site Scripting Library. ASP.NET server controls that encode using methods from the Anti-Cross Site Scripting Library will be provided in future releases of this library.

Q.Are there any additional resources I can read to learn how to protect my Web applications against XSS attacks?

A. Yes, please refer to the following resources from the patterns & practices teams: