Cross-site scripting is unusual among web vulnerabilities in that it targets the client instead of the web application itself.
According to NIST’s NVD, cross site scripting or XSS is the single most common vulnerability. It makes up ~12% of all vulnerabilities since 2008 by itself – total, not just in web applications! – and the ratio is increasing.
Cross site scripting has had a spot on the OWASP Top Ten since its inception, though it is not as stable as Injection. Starting off at #4 in 2003-2004, it catapulted to #1 in 2007, #2 in 2010, #3 in 2013, and finally #7 in 2017. Due to its high incidence rate, it is all but guaranteed to stay on the Top Ten, but there are some factors in its significant drop that are worth investigating.
First, let’s take a look at what the various types of cross site scripting are and how they work.
The commonly used classification of cross site scripting (from 2005, as per Amit Klein from WASC) differentiates between three subtypes depending on the source and destination (sink) of the attack string:
The main distinction between the server/client is where the malicious user input interacts with the logic used to generate or render the page, and what the developer can use to prevent the cross site scripting vulnerability.
Cross site scripting exploitation has undergone a lot of evolution since the early 1990s, with new techniques in the context of AJAX, HTML5 functionality, and even CSS3. On the other hand, the core cause of the vulnerability and its prevention has basically not changed.
Which brings us to the good news: the increased popularity of auto-escaping frameworks such as Angular / React / Razor / Jinja2 is directly responsible for cross site scripting being a much lower-risk vulnerability today than it was in 2004, which also explains why it only got 7th place in the OWASP Top Ten 2017. It is still possible to use user input in a vulnerable manner in those frameworks, but at least it takes deliberate effort now!