People's Newsroom


With a Cross-Site Scripting (XSS) attack, an attacker is able to execute his own JavaScript code within the application’s execution context, gaining him the same privileges as the target application code. This exposes all client-side application data, resources, and APIs to the attacker, including the possibility to manipulate and generate legitimate application requests towards the server-side application code. Cross-site scripting is a serious problem in the Web and is highly ranked in both the OWASP top ten of Web application vulnerabilities and the CWE/SANS Most dangerous programming errors. Almost every Web application on the Web has had a script injection vulnerability at some point, with even the serious players such as Google, Facebook, and Twitter not being exempted. Hence, cross-site scripting is often referred to as the buffer overflow of the Web.


The goal of a cross-site scripting (XSS) attack is to execute attacker-controlled code in the client-side application context within the victim’s browser. In an XSS attack, the attacker is able to inject JavaScript code into a page of the target application, mixing it with the legitimate page content, causing it to be executed altogether as the page is processed. Since the browser sees a single Web page, it is unable to distinguish between legitimate code and malicious code. XSS attacks can be carried out by the weakest threat model, the forum poster.

An attacker has many attack vectors to inject a payload into the target application. The first way is by manipulating the URI to inject code into request parameters, which are processed by a client-side script of the target application. Whenever the client-side script constructs code using these parameters, which it does not expect to hold code, the attacker’s code will be executed alongside the legitimate application code. This type of XSS attack is known as DOM-based XSS or XSS type 0.

The second class of XSS attacks consists of tricking the server into including the attacker’s code in its response. For example, if the attacker makes the victim’s browser visit the URI shown in Figure 2.8, the server will reflect the value of the URI parameter back in the response, where it will be executed as part of the requested page. This type is known as reflected XSS or XSS type. Finally, an attacker can also store the malicious code in the application’s data, for example by hiding it in a forum post or blog comment. Whenever the victim requests a page that includes the attacker’s content, the malicious code will be embedded in the page as well. This type of XSS is known as stored XSS or XSS type 2.

In essence, the problem of an XSS attack is the failure of the target application to recognize the insertion of code, thus allowing the payload to be executed. The combination of the facts that code can be placed anywhere in a document, and that browsers attempt to correct syntactically incorrect documents rather than rejecting or ignoring them helps the easy exploitation of injection vulnerabilities.

Mitigation Techniques

The traditional mitigation technique used against cross-site scripting attacks depends on sanitizing input and output, preventing any dangerous input from reaching the final output. These sanitization techniques attempted to simply replace or remove dangerous characters such as < > & ” ’ or check against a whitelist of allowed characters, but modern sanitization techniques take the context of the output into account. Modern Web applications generate output for different contexts, with different output formats and injection vectors. Some example contexts are HTML elements, HTML element attributes, CSS code, JavaScript code, etc. Several publicly available libraries provide context-sensitive content encoding and effectively mitigate XSS attacks. Popular examples for Java applications are the OWASP Java Encoder Project, which offers several context-specific sanitization operations, and OWASP’s Java XML Templates, which offer automatic context-aware encoding. Alternatively, HTML Purifier offers automatic sanitization for PHP applications and even ensures that the output is standards-compliant HTML. Automating context-sensitive sanitization is an active research topic. ScriptGard focuses on the detection of incorrect use of sanitization libraries (e.g., context-mismatched sanitization or inconsistent multiple sanitizations), and is capable of detecting and repairing incorrect placement of sanitizers. Other work focuses on achieving correct, context-sensitive sanitization, using a type-qualifier mechanism to be applied on existing Web templating frameworks.

Even with the most advanced mitigation techniques, both newly created and legacy applications remain vulnerable to XSS attacks. Therefore, Mozilla proposed Content Security Policy (CSP), a server-driven, browser-enforced policy to be used as a second line of defense. CSP allows a developer or administrator to strictly define the sources of included content, such as scripts, stylesheets, images, etc., preventing the inclusion of malicious scripts from sources unknown to or untrusted by the developer. Additionally, CSP prevents the execution of harmful inline content by default. When deploying CSP, a reporting-only mode is available. This mode will report any violations of the policy to the developer, without actually blocking any content. This allows to dry-run a policy before actually deploying it towards users. CSP’s restrictions on dangerous inline content effectively render injected script code harmless, since it will not be executed, and the list of trusted sources further limits an attacker when including a remote script file. Currently, CSP is being adopted by the major browsers and is on the standardization track of W3C. One downside of CSP is its impact on an application’s code, since the application is no longer allowed to use code files that mix HTML and JavaScript together, or dangerous features that interpret strings into code at runtime, such as the eval() function.

For newly developed applications, this is manageable, but legacy applications require some effort to be made compatible. As a response to this problem, the upcoming level 2 version of CSP will allow inline scripts if they possess a unique, unguessable nonce. Injected scripts will not be able to provide this nonce, and hence will not be executed. The detection of cross-site scripting vulnerabilities in Web applications commonly relies on penetration testing (colloquially referred to as pen-testing) and static analysis. In addition to these state-of-practice techniques, state-of-the-art research focuses on the discovery and detection of potential injection vulnerabilities. Kudzu achieves this using the symbolic execution of JavaScript. Gatekeeper, on the other hand, allows site administrators to express and enforce security and reliability policies for JavaScript programs and was successfully applied to automatically analyze JavaScript widgets, with very few false positives and no false negatives.


Injection vulnerabilities leading to XSS attacks are prevalent in both new and legacy Web applications. A large-scale analysis of the Alexa top 5,000 sites has discovered 6,167 unique XSS vulnerabilities, distributed over 480 domains. Cross-site scripting attacks are often only the first step in a more complicated attack, involving underlying infrastructure or higher-privilege accounts. The consequences of escalating an XSS attack are aptly demonstrated by exploitation frameworks, such as the Browser Exploitation Framework (BeEF) or Metasploit. Currently, almost every newly developed Web application sanitizes its inputs and outputs, in an attempt to avoid injection vulnerabilities altogether. Most modern development frameworks offer library support for sanitization.

Unfortunately, sanitization libraries are not always context-sensitive, and many applications apply sanitization procedures wrongly or inconsistently. Additionally, a few context-sensitive sanitization libraries are available, as discussed above as an aspect of mitigation techniques. Since injection vulnerabilities remain widespread, several attempts have been made to stop them from within the browser, independent of any application-specific mitigation techniques. Examples of in-browser mitigation techniques are XSS filters, or the popular security add-on NoScript. The newly introduced Content Security Policy (CSP) is slowly starting to be adopted. July 2014 survey of the Alexa top 10,000 sites found 131 sites that already issue a CSP policy in their response headers.

Additionally, applications often apply code-based isolation techniques to prevent the damage that can be done by untrusted or injected scripts. Examples of currently available isolation techniques are HTML 5 sandboxes, or browser-based sanitization procedures for dynamic script code, such as Internet Explorer to StaticHTML().

Back to top button