This is a fine article with good explanations, practical examples and interesting links for ongoing efforts in the field of web security.<p>I do however wish more emphasis were put on exactly how to address the fundamental problem of cross-site scripting: making sure data is properly encoded for the context. This article touches on it quite a bit with its mentions of "mixing code and data", but I wish the author was clearer.<p>For example, jumping to input sanitization as the "first line of defense" implies---at least to me---that this is the most important. It's not. Whether sanitization (or validation) can make sure the data does not contain code is completely dependent on what the data is expected to contain. The obvious example is software development sites that handle actual code, even code for the very web technologies used to display them. Yes, sanitization (and validation) has its place, but relying on it to avoid cross-site scripting is taking a shortcut that can backfire once the data rules change.<p>The fundamental cause of a cross-site scripting vulnerability---or rather web page injection vulnerability---is the improper encoding of output data. (If there are cross-site scripting vulnerabilities that are not caused by some injection attack then by all means, let me know.) The reason for the improper encoding can be a combination of many factors. Examples include: Lack of a parameterized interface that properly encodes; A developer forgetting to invoke the appropriate encodes function; A developer calling the wrong encoding function; The <i>design choice</i> of mixing code and data so that the proper encoding must be applied far away from the point of use and is forgotten.<p>All the mitigating measures mentioned in the article have their place as each part of the application should as best it can protect itself. For example, Content Security Policy is great for preventing the browser to execute a <i>successfully injected attack</i> because with it the application can express the fact that it does not rely on inline scripts, say.<p>The reason I think it is beneficial to emphasize the fundamental solution to web page injection vulnerabilities is that it extends to all other injection attacks and brings clarity to a topic with a long history of confusion.