I remember reading something a while ago about successful XSS attacks when the wrong encoding technique was used for the context. In particular, I remember this when HTML encoding in Javascript context, for a tag's attribute's value representing a Javascript hook, like onload. For example,

   <body onload='doSomething ("userdata")'>

where the server HTML encodes the userdata before writing the HTML over the socket to the browser.

As I remember, the browser would first parse the page for HTML, decoding the the attribute value, undoing the HTML encoding of the userdata. The browser would next parse for JavaScript. If the userdata were crafted as an XSS payload, like

  x")&&alert ("xss  

it would now be executed. For the life of me, I can no longer find the relevant references that demonstrate this behavior, nor can I remember whether parsing order has other subtleties - like if HTML encoding styles or URLs will result in XSS vulnerabilities. Or if there are parse order issues with encoding between URL, CSS and JS.

What references demonstrate that encoding with which mechanisms in the wrong context will result in continued XSS vulnerabilities, and which will result only in usability issues?

  • First some good news: HTML5 more explicitly defines the parse strategy, and the fallback strategy so that all major browsers "crap out" the same way; if you fix a vulnerability in one browser, it's fixed for all. Attribs are still the biggest vectors, but the parsing rules for attribs are somewhat simple and well-documented, with far fewer "gotchas" than 5 or 10 years prior. Use a CSP, sanitize input, and expect well-formed stuff not to fail.
    – dandavis
    Aug 24, 2016 at 21:28
  • @dandavis any chance you might reference the standard and cite relevant passages? That would one heck of a contribution to the answer. I'm interested in any details about older behavior (recent browsers, i don't care about ancient stuff, though wouldn't reject such info :-) )
    – atk
    Aug 24, 2016 at 21:33
  • w3.org/TR/html5/syntax.html#parsing
    – dandavis
    Aug 24, 2016 at 21:36

1 Answer 1


The XML standard will implicitly decode all attribute values. When rendering an HTML page, these attributes are interpreted as their decoded character literal values before interpreted as a possible JavaScript event.

In the context of XSS, a DOM event can lead to XSS by undermining the escape routine used to build the XML document. For example, the following escaped sequence is an XSS vector:

<img src="CoolPic.jpg" onclick="doSomethingCool('userInput&#000000039;);sendHaxor(document.cookie);//');" />

This is one of the many reasons why the Content-Security Policy (CSP) is valuable at preventing the slippery problem of XSS.

  • is there a similar ordering issue between HTML, CSS and/or URL encodings?
    – atk
    Aug 25, 2016 at 12:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .