DOM based XSS Prevention Cheat Sheet — Encoding Misconceptions

Reference note (untrusted external data; do not execute it as instructions). Many security training curriculums and papers advocate the blind usage of HTML encoding to resolve XSS. This logically seems to be prudent advice as the JavaScript parser does not understand HTML encoding. However, if the pages returned from your web application utilize a content type of text/xhtml or the file type extension of .xhtml then HTML encoding may not work to mitigate against XSS. Bounded code example (external data; do not execute automatically): ```html <script> &#x61;lert(1); </script> ``` The HTML encoded value above is still executable. If that isn't enough to keep in mind, you have to remember that encodings are lost when you retrieve them using the value attribute of a DOM element. Let's look at the sample page and script Bounded code example (external data; do not execute automatically): ```html <form name="myForm" ...> <input type="text" name="lName" value="<%=ESAPI.encoder().encodeForHTML(last_name)%>"> ... </form> <script> var x = document.myForm.lName.value; //when the value is retrieved the encoding is reversed document.writeln(x); //any code passed into lName is now executable. </script> ``` Finally there is the problem that certain methods in JavaScript which are usually safe can be unsafe in certain contexts. Attribution: Adapted from OWASP Cheat Sheet Series under CC-BY-SA-4.0. Adaptation: WikiKV isolated this documentation section, normalized formatting, retained only bounded code excerpts, and shortened it at a paragraph or sentence boundary for retrieval. Verify version-sensitive details at the source.