XSS (Cross Site Scripting) Prevention Cheat Sheet - Revision history

Dominique RIGHETTO: Point to the official site

2019-07-15T13:49:06Z

Point to the official site

Dominique RIGHETTO: Rename the XSS CS on GH so update the link

2019-02-16T09:19:00Z

Rename the XSS CS on GH so update the link

Thunder-Son: Migration to GitHub

2019-02-14T15:22:05Z

Migration to GitHub

Show changes

Tanyajanca: Removed this dead link:A Systematic Analysis of XSS Sanitization in Web Application Frameworks http://www.cs.berkeley.edu/~prateeks/papers/empirical-webfwks.pdf

2018-10-09T01:32:44Z

Removed this dead link:A Systematic Analysis of XSS Sanitization in Web Application Frameworks http://www.cs.berkeley.edu/~prateeks/papers/empirical-webfwks.pdf

Jmanico: updating JS Encoding rules to discuss quoting more indepth

2018-08-15T20:18:20Z

updating JS Encoding rules to discuss quoting more indepth

Jmanico: augmenting the JSON embedding rules from encoding to serialization

2018-05-09T20:30:37Z

augmenting the JSON embedding rules from encoding to serialization

Jmanico: fixing broken page

2018-03-06T20:48:41Z

fixing broken page

Jmanico: removing "donate to owasp" link which broke the page

2018-03-06T20:47:58Z

removing "donate to owasp" link which broke the page

Hblankenship: Added Donate to OWASP button per the OWASP Donation Initiative

2018-01-27T14:47:32Z

Added Donate to OWASP button per the OWASP Donation Initiative

Peter Mosmans: Grammar correction

2017-10-15T03:22:54Z

Grammar correction

← Older revision		Revision as of 13:49, 15 July 2019
Line 4:		Line 4:
	The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!		The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!

−	Please visit [https://~~github~~.~~com/OWASP/CheatSheetSeries/blob/master~~/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md XSS (Cross Site Scripting) Prevention Cheat Sheet] to see the latest version of the cheat sheet.	+	Please visit [https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html XSS (Cross Site Scripting) Prevention Cheat Sheet] to see the latest version of the cheat sheet.

← Older revision		Revision as of 09:19, 16 February 2019
Line 4:		Line 4:
	The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!		The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!

−	Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/~~XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet~~.md XSS (Cross Site Scripting) Prevention Cheat Sheet] to see the latest version of the cheat sheet.	+	Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md XSS (Cross Site Scripting) Prevention Cheat Sheet] to see the latest version of the cheat sheet.

@@ Line 3: / Line 3: @@
 {| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
-| valign="top"  style="border-right: 1px dotted gray;padding-right:25px;" |
+| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
 Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 = Introduction  =
@@ Line 66: / Line 66: @@
    &lt;body>'''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'''</body>
-  &lt;div>'''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'''</div>
+&lt;div>'''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'''
    any other normal HTML elements
@@ Line 83: / Line 83: @@
 Rule #2 is for putting untrusted data into typical attribute values like width, name, value, etc. This should not be used for complex attributes like href, src, style, or any of the event handlers like onmouseover.  It is extremely important that event handler attributes should follow Rule #3 for HTML JavaScript Data Values.
-  &lt;div attr='''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'''>content</div>     inside UNquoted attribute
+&lt;div attr='''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'''>content
-  &lt;div attr=''''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...''''>content</div>   inside single quoted attribute
+&lt;div attr='<nowiki/>'''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...''''>content
-  &lt;div attr="'''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'''">content</div>   inside double quoted attribute
+&lt;div attr="'''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'''">content
 Except for alphanumeric characters, escape all characters with ASCII values less than 256 with the &amp;#xHH; format (or a named entity if available) to prevent switching out of the attribute. The reason this rule is so broad is that developers frequently leave attributes unquoted.  Properly quoted attributes can only be escaped with the corresponding quote. Unquoted attributes can be broken out of with many characters, including [space] % * + , - / ; < = > ^ and |.
@@ Line 95: / Line 101: @@
 Rule #3 concerns dynamically generated JavaScript code - both script blocks and event-handler attributes. The only safe place to put untrusted data into this code is inside a quoted "data value."  Including untrusted data inside any other JavaScript context is quite dangerous, as it is extremely easy to switch into an execution context with characters including (but not limited to) semi-colon, equals, space, plus, and many more, so use with caution.
-   &lt;script>alert(''''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'''')&lt;/script>     inside a quoted string
+   &lt;script>alert('<nowiki/>'''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'''')&lt;/script>     inside a quoted string
-   &lt;script>x=''''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...''''&lt;/script>          one side of a quoted expression
+   &lt;script>x='<nowiki/>'''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...''''&lt;/script>          one side of a quoted expression
-   &lt;div onmouseover="x=''''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...''''"&lt;/div>  inside quoted event handler
+   &lt;div onmouseover="x='<nowiki/>'''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...''''"&lt;/div>  inside quoted event handler
 Please note there are some JavaScript functions that can never safely use untrusted data as input - <b>EVEN IF JAVASCRIPT ESCAPED</b>!
@@ Line 105: / Line 111: @@
 For example:
    &lt;script>
-   window.setInterval(''''...EVEN IF YOU ESCAPE UNTRUSTED DATA YOU ARE XSSED HERE...'''');
+   window.setInterval('<nowiki/>'''...EVEN IF YOU ESCAPE UNTRUSTED DATA YOU ARE XSSED HERE...'''');
    &lt;/script>
@@ Line 116: / Line 122: @@
 In a Web 2.0 world, the need for having data dynamically generated by an application in a javascript context is common.  One strategy is to make an AJAX call to get the values, but this isn't always performant.  Often, an initial block of JSON is loaded into the page to act as a single place to store multiple values.  This data is tricky, though not impossible, to escape correctly without breaking the format and content of the values.
-'''Ensure returned ''Content-Type'' header is application/json and not text/html.
+'''Ensure returned ''Content-Type'' header is application/json and not text/html. '''
-This shall instruct the browser not misunderstand the context and execute injected script'''
+This shall instruct the browser not misunderstand the context and execute injected script
 '''Bad HTTP response:'''
@@ Line 172: / Line 178: @@
 Rule #4 is for when you want to put untrusted data into a stylesheet or a style tag. CSS is surprisingly powerful, and can be used for numerous attacks. Therefore, it's important that you only use untrusted data in a property '''value''' and not into other places in style data. You should stay away from putting untrusted data into complex properties like url, behavior, and custom (-moz-binding). You should also not put untrusted data into IE’s expression property value which allows JavaScript.
-   &lt;style>selector { property : '''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'''; } &lt;/style>     property value<br/>
+   &lt;style>selector { property : '''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'''; } &lt;/style>     property value<br />
-   &lt;style>selector { property : &quot;'''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'''&quot;; } &lt;/style>   property value<br/>
+   &lt;style>selector { property : &quot;'''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'''&quot;; } &lt;/style>   property value<br />
    &lt;span style=&quot;property : '''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'''&quot;>text&lt;/span>       property value
@@ Line 229: / Line 235: @@
     &lt;%= sanitize @comment.body, tags: %w(strong em a), attributes: %w(href) %&gt;
-'''Other libraries that provide HTML Sanitization include:'''<br/>
+'''Other libraries that provide HTML Sanitization include:'''<br />
-PHP HTML Purifier - http://htmlpurifier.org/<br/>
+PHP HTML Purifier - http://htmlpurifier.org/<br />
-JavaScript/Node.js Bleach - https://github.com/ecto/bleach<br/>
+JavaScript/Node.js Bleach - https://github.com/ecto/bleach<br />
 Python Bleach - https://pypi.python.org/pypi/bleach
@@ Line 288: / Line 294: @@
 | String
 | Untrusted URL in a SRC or HREF attribute
-| &lt;a href="<span style="color:red;">UNTRUSTED URL</span>">clickme&lt;/a><br/>&lt;iframe src="<span style="color:red;">UNTRUSTED URL</span>" />
+| &lt;a href="<span style="color:red;">UNTRUSTED URL</span>">clickme&lt;/a><br />&lt;iframe src="<span style="color:red;">UNTRUSTED URL</span>" />
 | <ul><li>Canonicalize input</li><li>URL Validation</li><li>Safe URL verification</li><li>Whitelist http and https URL's only ([[Avoid the JavaScript Protocol to Open a new Window]])</li><li>Attribute encoder</li></ul>
 |-
@@ Line 298: / Line 304: @@
 | String
 | JavaScript Variable
-| &lt;script>var currentValue='<span style="color:red;">UNTRUSTED DATA</span>';&lt;/script><br/>&lt;script>someFunction('<span style="color:red;">UNTRUSTED DATA</span>');&lt;/script>
+| &lt;script>var currentValue='<span style="color:red;">UNTRUSTED DATA</span>';&lt;/script><br />&lt;script>someFunction('<span style="color:red;">UNTRUSTED DATA</span>');&lt;/script>
 | <ul><li>Ensure JavaScript variables are quoted</li><li>JavaScript Hex Encoding</li><li>JavaScript Unicode Encoding</li><li>Avoid backslash encoding (\" or \' or \\)</li></ul>
 |-
@@ Line 324: / Line 330: @@
 |-
 | HTML Entity Encoding
-|   Convert & to &amp;amp;<br/>Convert < to &amp;lt;<br/>Convert > to &amp;gt;<br/>Convert " to &amp;quot;<br/>Convert ' to &amp;#x27;<br/>Convert / to &amp;#x2F;
+|   Convert & to &amp;amp;<br />Convert < to &amp;lt;<br />Convert > to &amp;gt;<br />Convert " to &amp;quot;<br />Convert ' to &amp;#x27;<br />Convert / to &amp;#x2F;
 |-
 | HTML Attribute Encoding
@@ Line 330: / Line 336: @@
 |-
 | URL Encoding
-| Standard percent encoding, see: [http://www.w3schools.com/tags/ref_urlencode.asp http://www.w3schools.com/tags/ref_urlencode.asp]. URL encoding should only be used to encode parameter values, not the entire URL or path fragments of a URL.
+| Standard percent encoding, see: http://www.w3schools.com/tags/ref_urlencode.asp. URL encoding should only be used to encode parameter values, not the entire URL or path fragments of a URL.
 |-
 | JavaScript Encoding
@@ Line 346: / Line 352: @@
 * OWASP: [[XSS Filter Evasion Cheat Sheet]] - Based on - RSnake's: "XSS Cheat Sheet"
 '''Description of XSS Vulnerabilities'''
@@ Line 374: / Line 376: @@
 = Authors and Primary Editors =
-Jeff Williams - jeff.williams[at]contrastsecurity.com<br/>
+Jeff Williams - jeff.williams[at]contrastsecurity.com<br />
-Jim Manico - jim[at]owasp.org<br/>
+Jim Manico - jim[at]owasp.org<br />
 Neil Mattatall - neil[at]owasp.org
 [[Category:Cheatsheets]]
 [[Category:Popular]]

@@ Line 110: / Line 110: @@
 Except for alphanumeric characters, escape all characters less than 256 with the \xHH format to prevent switching out of the data value into the script context or into another attribute. DO NOT use any escaping shortcuts like \" because the quote character may be matched by the HTML attribute parser which runs first. These escaping shortcuts are also susceptible to "escape-the-escape" attacks where the attacker sends \" and the vulnerable code turns that into \\" which enables the quote.
-If an event handler is properly quoted, breaking out requires the corresponding quote. However, we have intentionally made this rule quite broad because event handler attributes are often left unquoted.  Unquoted attributes can be broken out of with many characters including [space] % * + , - / ; < = > ^ and |. Also, a </script> closing tag will close a script block even though it is inside a quoted string because the HTML parser runs before the JavaScript parser.
+If an event handler is properly quoted, breaking out requires the corresponding quote. However, we have intentionally made this rule quite broad because event handler attributes are often left unquoted.  Unquoted attributes can be broken out of with many characters including [space] % * + , - / ; < = > ^ and |. Also, a </script> closing tag will close a script block even though it is inside a quoted string because the HTML parser runs before the JavaScript parser. Please note this is an aggressive escaping policy that over-encodes. If there is a guarantee that proper quoting is accomplished then a much smaller character set is needed.  Please look at the OWASP Java Encoder JavaScript escaping examples for examples of proper JavaScript use that requires minimal escaping. https://www.owasp.org/index.php/OWASP_Java_Encoder_Project#tab=Use_the_Java_Encoder_Project
 === RULE #3.1 - HTML escape JSON values in an HTML context and read the data with JSON.parse ===

@@ Line 149: / Line 149: @@
      &lt;/script>
-==== JSON entity encoding ====
+==== JSON serialization ====
-The rules for JSON encoding can be found in the [https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#Output_Encoding_Rules_Summary Output Encoding Rules Summary]. Note, this will not allow you to use XSS protection provided by CSP 1.0.
+A safe JSON serializer will allow developers to serialize JSON as string of literal JavaScript which can be embedded in an HTML in the contents of the <script> tag. HTML characters and JavaScript line terminators need be escaped. Consider the Yahoo JavaScript Serializer for this task. https://github.com/yahoo/serialize-javascript
 ==== HTML entity encoding ====

@@ Line 370: / Line 370: @@
 = Other Cheatsheets =
 {{Cheatsheet_Navigation_Body}}
 = Authors and Primary Editors =

@@ Line 369: / Line 369: @@
 * [[XSS Experimental Minimal Encoding Rules]]
 = Authors and Primary Editors =
@@ Line 375: / Line 380: @@
 Neil Mattatall - neil[at]owasp.org
-= Other Cheatsheets =
+== Donate to OWASP ==
+<div class="center" style="width: auto; margin-left: auto; margin-right: auto;">{{#widget:PayPal Donation
-{{Cheatsheet_Navigation_Body}}
+|target=_blank
+|budget=Other (Website Donation) }}</div>
 [[Category:Cheatsheets]]
 [[Category:Popular]]

@@ Line 22: / Line 22: @@
 Given the way browsers parse HTML, each of the different types of slots has slightly different security rules. When you put untrusted data into these slots, you need to take certain steps to make sure that the data does not break out of that slot into a context that allows code execution. In a way, this approach treats an HTML document like a parameterized database query - the data is kept in specific places and is isolated from code contexts with escaping.
-This document sets out the most common types of slots and the rules for putting untrusted data into them safely. Based on the various specifications, known XSS vectors, and a great deal of manual testing with all the popular browsers, we have determined that the rule proposed here are safe.
+This document sets out the most common types of slots and the rules for putting untrusted data into them safely. Based on the various specifications, known XSS vectors, and a great deal of manual testing with all the popular browsers, we have determined that the rules proposed here are safe.
 The slots are defined and a few examples of each are provided. Developers SHOULD NOT put data into any other slots without a very careful analysis to ensure that what they are doing is safe. Browser parsing is extremely tricky and many innocuous looking characters can be significant in the right context.