Output Encoding Contexts
The following rules are intended to prevent XSS in Web applications. The list of contexts and especially the categories of problems which are classified to these rules are dynamic. This guide is based on the XSS Prevention Rules from OWASP, so if this guide does not provide the appropriate help for you, you can find more information about prevention rules from OWASP. See http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.230_-_Never_Insert_Untrusted_Data_Except.
HTML or XML Content and Attributes
Validity
This context is valid if you insert untrusted data between HTML or XML tags or attributes.
Example 1 (HTML tag):
<p>...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE...</p>
Example 2 (HTML attribute value)
<div title="...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE...">
Rules and Recommendations
The data needs to be HTML encoded. This context combines the OWASP RULE #1 and RULE #2 as described at http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.231_-_HTML_Escape_Before_Inserting_Untrusted_Data_into_HTML_Element_Content.
This context should not be used for special tags or attributes which are opening different contexts like <script> , <style> , href , src , style or any of the event handlers like onmouseover .
Examples
<div> ...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE... </div>
<div title="...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE...">text</div>
<img alt="...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE..." src="img.gif>
element.innerHTML = '...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE... '
document.write('<p>...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE...</p>');
document.createElement('...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE...')HTML or XML Tag and Attribute Names
Validity
This context is valid when inserting data as tag or attribute names in HTML.
Rules and Recommendations
Encoding cannot help to prevent XSS in this context. This is an OWASP rule #0 scenario (see http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.230_-_Never_Insert_Untrusted_Data_Except_in_Allowed_Locations).
Avoid using it. If it is really needed, the use of a whitelist filter is required.
Examples
<...NEVER PUT UNTRUSTED DATA HERE...>
<div ...NEVER PUT UNTRUSTED DATA HERE...="abc">
JavaScript Inside HTML
Validity
This context is valid for script tags and all event handler attributes in HTML, for example, <button onclick="...NEVER PUT UNTRUSTED DATA HERE..."> .
Rules and Recommendations
While HTML encoding would prevent breaking out of the HTML context, it will still be processed and executed by the JavaScript engine. Never put untrusted data directly inside a script. The only safe place to put properly encoded untrusted data in the context of JavaScript is a quoted data value. For information about how to properly encode in the JavaScript context, see the JavaScript Context section.
Examples
<body onload="...NEVER PUT UNTRUSTED DATA HERE...">
<script>...NEVER PUT UNTRUSTED DATA HERE...</script>
CSS Inside HTML
Validity
This context is valid for the style tag and style attribute in HTML, for example, <div style="...NEVER PUT UNTRUSTED DATA HERE..."> .
Rules and Recommendations
While HTML encoding would prevent breaking out of the HTML context, it will still be processed by the CSS parser. For more information about how to properly encode in the CSS context, see the CSS (Cascading Stylesheets) section.
Examples
<p style="...NEVER PUT UNTRUSTED DATA HERE...">
<style>...NEVER PUT UNTRUSTED DATA HERE...</style>
URL Inside HTML
Validity
This context is valid for all attributes containing URLs such as src, action or href in HTML, for example, <a href="...NEVER PUT UNTRUSTED DATA HERE..."> .
Rules and Recommendations
While HTML encoding would prevent breaking out of the HTML context, it will still be processed by the URL parser and cause a request or JavaScript execution (javascript:-URLs). For more information about how to properly handle URLs, see the URL section.
Examples
<script src="...NEVER PUT UNTRUSTED DATA HERE..."></script>
<img src="...NEVER PUT UNTRUSTED DATA HERE...">
<form action="...NEVER PUT UNTRUSTED DATA HERE...">
<iframe src="...NEVER PUT UNTRUSTED DATA HERE..."></iframe>
<link rel="stylesheet" type="text/css" href="...NEVER PUT UNTRUSTED DATA HERE..."></link>
HTML Inside HTML
Validity
This context is valid when HTML is nested within HTML.
Rules and Recommendations
HTML encoding cannot prevent XSS in this case, as the data is processed by HTML parser twice. While it is theoretically possible to correctly encode in this scenario using multiple encodings, it is hard to understand and is error prone. Therefore, in such cases, we recommend restructuring your page to avoid such scenarios.
Example
<div onclick="this.innerHTML='...NEVER PUT UNTRUSTED DATA HERE...'">text</div>
Complete URLs
Validity
This context is valid whenever untrusted data contains a complete URL, for example, < img src="...NEVER PUT UNTRUSTED DATA HERE..."> .
Rules and Recommendations
There is no possibility to properly encode a complete URL without breaking it. Instead, a URL validator must be used to ensure that the URL is valid according to the URI specification. This validation might include a limitation of allowed protocols and target hosts. For more information, see Sanitizer Methods on AS Java .
Examples
location.href = "...NEVER PUT UNTRUSTED DATA HERE..."
.image { background-image: url('...NEVER PUT UNTRUSTED DATA HERE...')}
iframe.src = "...NEVER PUT UNTRUSTED DATA HERE..."
<form method="POST" action="...NEVER PUT UNTRUSTED DATA HERE...">
URL Parameter Names and Values
Validity
This context is valid for parameter names and values contained in the query string of a URL, for example, http://host?name=...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE....
Rules and Recommendations
It is defined with regards to OWASP RULE #5 (see https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.235_-_URL_Escape_Before_Inserting_Untrusted_Data_into_HTML_URL_Parameter_Values). There is a special case where the query is a single data value instead of using named parameters that is also covered by this context.
Examples
http://www.google.de?q=...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE...
https://host.tld/createimg?...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE...
http://appserver/myapp?...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE...=true
URL Path and File Name Parts
Validity
This context is valid for path and file names in the path section of a URL, for example, http://host/...NEVER PUT UNTRUSTED DATA HERE....
Rules and Recommendations
To prevent directory traversal attacks, you should avoid this context. In case it is required to put user data into a URL path, you should use a whitelist filter and you should validate the constructed URL using a URL validator. For more information, see Sanitizer Methods on AS Java .
Examples
ftp://ftpserver/images/...NEVER PUT UNTRUSTED DATA HERE...
http://myserver.com/...NEVER PUT UNTRUSTED DATA HERE.../index.html
URL Host Name and Port
Validity
This context is valid for the host name and port of a URL, for example, http://...NEVER PUT UNTRUSTED DATA HERE.../ .
While this is dangerous, it is a common use case to allow input of host names or URLs, for example, in user or company profiles.
Rules and Recommendations
If possible, use a whitelist. If a whitelist is not possible, at least check for allowed characters and validate the constructed URL with a URL validator. For more information, see Sanitizer Methods on AS Java .
URL Protocol
Validity
This context is valid for the protocol section of a URL, for example, ...NEVER PUT UNTRUSTED DATA HERE...://host/index.html .
Rules and Recommendations
Obviously allowing untrusted data in the protocol section of a URL can lead to creation of malicious URLs and you should avoid it.
Strict whitelist filtering is required in this case, and you must validate the constructed URL with a URL validator. For more information, see Sanitizer Methods on AS Java .
String Literal
Validity
This context is valid when inserting data within JavaScript string literals, for example, "...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE...", '...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE...' .
Rules and Recommendations
This is the most common case where escaping inside JavaScript content is needed as defined with OWASP rule #3 (see http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.233_-_JavaScript_Escape_Before_Inserting_Untrusted_Data_into_HTML_JavaScript_Data_Values).
Examples
var s = "...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE..."
alert("...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE...");
<button onclick="this.value = '...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE...'">
if (s == '...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE...') {...}Number or Boolean
Validity
This context is valid when inserting data into JavaScript Boolean or number expressions, for example, var n = ...NEVER PUT UNTRUSTED DATA HERE....
Rules and Recommendations
This case cannot be secured by using escaping. Instead, the application has to ensure it has trusted data. This means the data inserted in this context either needs to be provided from a number or Boolean type variable, or needs to be validated to only contain allowed characters for the needed type.
Examples
var n = 23 + ...NEVER PUT UNTRUSTED DATA HERE...;
if (...NEVER PUT UNTRUSTED DATA HERE...) {...}Arbitrary Script Code
This context is valid when inserting data directly into JavaScript code, for example, <script>...NEVER PUT UNTRUSTED DATA HERE...</script> .
Rules and Recommendations
This case cannot be secured by escaping or validation and falls in OWASP RULE #0 (See http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.230_-_Never_Insert_Untrusted_Data_Except_in_Allowed_Locations).
Examples
<script>...NEVER PUT UNTRUSTED DATA HERE...</script>
<button onclick="...NEVER PUT UNTRUSTED DATA HERE...">
eval("...NEVER PUT UNTRUSTED DATA HERE...");
setTimeout("...NEVER PUT UNTRUSTED DATA HERE...", 1000);HTML Inside JavaScript
Validity
This context is valid when inserting data into HTML inside a JavaScript string literal, for example, obj.innerHTML="<b>...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE..</b>" .
Rules and Recommendations
While JavaScript encoding would prevent breaking out of the JavaScript context, the data is will still be parsed and processed by the HTML parser. For more information about how to encode HTML, see the HTML/XML section.
Examples
document.write("<h1>...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE..</h1>");
obj.innerHTML = "<h1>...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE..</h1>";
URL Inside JavaScript
Validity
This context is valid when inserting data into a URL within a JavaScript string literal, for example, location.href="...NEVER PUT UNTRUSTED DATA HERE..." .
Rules and Recommendations
While JavaScript encoding would prevent breaking out of the JavaScript context, the data is will still be processed by the URL parser, and will cause a request or execute JavaScript. For more information about how to handle URLs, see the URL section.
Examples
location.href="...NEVER PUT UNTRUSTED DATA HERE...";
img.src="...NEVER PUT UNTRUSTED DATA HERE...";
window.open("...NEVER PUT UNTRUSTED DATA HERE...");JavaScript Inside JavaScript
Validity
This context is valid when inserting data into JavaScript that is itself embedded in a JavaScript string literal, for example, eval("alert(\"...NEVER PUT UNTRUSTED DATA HERE...\")"); .
Rules and Recommendations
While it is theoretically possible to apply multiple encodings in this cases, it is hard to understand and error prone. Therefore, in such cases, we recommend restructuring your page to avoid nested contexts.
Examples
setTimeout("input.value = \"...NEVER PUT UNTRUSTED DATA HERE...\";", 1000);
setInterval("input.value = \"...NEVER PUT UNTRUSTED DATA HERE...\";", 1000);
document.write("<button onclick=\"this.value='...NEVER PUT UNTRUSTED DATA HERE...'\">");In general, you should not generate CSS from user data, but instead use static CSS files. Generating CSS from user data contains many pitfalls.
Selectors and Rules
Validity
This context is valid when inserting data as a CSS selector, for example, ... NEVER PUT UNTRUSTED DATA HERE... { ...NEVER PUT UNTRUSTED DATA HERE...} .
Rules and Recommendations
There is no possibility to encode this in a way that it is still functional, therefore, you should never do it this way.
Examples
.myclass ...NEVER PUT UNTRUSTED DATA HERE... { color:red}
div { ...NEVER PUT UNTRUSTED DATA HERE...}Identifiers
Validity
This context is valid when inserting data into identifiers used within CSS selectors, for example, #...ENCODE UNTRUSTED DATABEFORE PUTTING HERE... { color: red} .
Rules and Recommendations
When generating CSS sheets, all identifiers, make sure you properly escape HTML IDs and class names according to OWASP rule #4 (see http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.234_-_CSS_Escape_Before_Inserting_Untrusted_Data_into_HTML_Style_Property_Values).
Examples
#...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE... {color:red}
....ENCODE UNTRUSTED DATA BEFORE PUTTING HERE... {color:green}Property Values
Validity
This context is valid when inserting data into CSS property values, for example, div { width: ...NEVER PUT UNTRUSTED DATA HERE...} .
Rules and Recommendations
These values cannot be encoded. Use a whitelist or validator to ensure valid CSS property values instead.
Examples
.myclass { color: ...NEVER PUT UNTRUSTED DATA HERE...}
a { font-family: ...NEVER PUT UNTRUSTED DATA HERE...}
<div style="width: ...NEVER PUT UNTRUSTED DATA HERE...">
String Literals
Validity
This context is valid when inserting data into string literals, for example, #myid { content: "...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE..."} .
Rules and Recommendations
For this context, you must encode the data according to OWASP rule #4 (http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.234_-_CSS_Escape_Before_Inserting_Untrusted_Data_into_HTML_Style_Property_Values).
Examples
a:after {content: "...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE..."}
a[title=...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE...] {color:red}URL Inside CSS
Validity
This context is valid when inserting URLs into CSS property values, for example, #myid { background-image: url(...NEVER PUT UNTRUSTED DATA HERE...)} .
Rules and Recommendations
While encoding this data would help prevent leaving the CSS context, there are other issues with URLs that need to be treated in a special way. For more information about how to handle URLs, see the URL section.
Examples
a:after {content: url('...NEVER PUT UNTRUSTED DATA HERE...')}
body {background-image: url('...NEVER PUT UNTRUSTED DATA HERE...')}