DOM based XSS Prevention Cheat Sheet

Revision as of 06:32, 20 March 2014 by Jmanico (Talk | contribs)

Jump to: navigation, search
OWASP Project Header.jpg


When looking at XSS (Cross-Site Scripting), there are three generally recognized forms of XSS. Reflected, Stored, and DOM Based XSS. The XSS Prevention Cheatsheet does an excellent job of addressing Reflected and Stored XSS. This cheatsheet addresses DOM (Document Object Model) based XSS and is an extension (and assumes comprehension of) the XSS Prevention Cheatsheet.

In order to understand DOM based XSS, one needs to see the fundamental difference between Reflected and Stored XSS when compared to DOM based XSS. Reflected and Stored XSS are server side execution issues while DOM based XSS is a client (browser) side execution issue. All of this code originates on the server, which means it is the application owner's responsibility to make it safe from XSS, regardless of the type of XSS flaw it is.

When a browser is rendering HTML and any other associated content like CSS, javascript, etc. it identifies various rendering contexts for the different kinds of input and follows different rules for each context. A rendering context is associated with the parsing of HTML tags and their attributes. The HTML parser of the rendering context dictates how data is presented and laid out on the page and can be further broken down into the standard contexts of HTML, HTML attribute, URL, and CSS. The JavaScript or VBScript parser of an execution context is associated with the parsing and execution of script code. Each parser has distinct and separate semantics in the way they can possibly execute script code which make creating consistent rules for mitigating vulnerabilities in various contexts difficult. The complication is compounded by the differing meanings and treatment of encoded values within each subcontext (HTML, HTML attribute, URL, and CSS) within the execution context.

For the purposes of this article, we refer to the HTML, HTML attribute, URL, and CSS Cheatsheet contexts as subcontexts because each of these contexts can be reached and set within a JavaScript execution context. In JavaScript code, the main context is JavaScript but with the right tags and context closing characters, an attacker can try to attack the other 4 contexts using equivalent JavaScript DOM methods.

Authors and Contributing Editors

Jim Manico - jim[at]
Abraham Kang - abraham.kang[at]
Gareth (Gaz) Heyes
Stefano Di Paola
Achim Hoffmann - achim[at]
Robert (RSnake) Hansen
Mario Heiderich
John Steven
Chris (Chris BEEF) Schmidt
Mike Samuel
Jeremy Long
Eduardo (SirDarkCat) Alberto Vela Nava
Jeff Williams - jeff.williams[at]
Erlend Oftedal

Other Cheatsheets