What Is Cross-Site Scripting?

The ability to run scripts is one of the features that makes modern websites so powerful. Using languages such as JavaScript, websites can execute custom code to achieve goals like providing interactive features or deploying content that is personalized for each user.

But website scripting also creates a risk: If malicious parties manage to trick a website into running malicious code, they could execute what's known as a cross-site scripting, or XSS, attack. XSS attacks allow threat actors to run code within unsuspecting users' browsers. Using this approach, attackers can steal sensitive information, impersonate users, or cause other forms of harm. That's why it's critical for website developers and admins to understand how XSS attacks happen and what they can do to protect users against them.

Related: Cross-Site Scripting Attacks: How to Protect Your Website

This article explains how cross-site scripting works, which techniques attackers use to execute XSS attacks, and what developers can do to mitigate the risk of XSS threats.

What Is Cross-Site Scripting?

Cross-site scripting, or XSS, is an attack technique in which threat actors run malicious scripts on websites. The scripts are most commonly executed using JavaScript, but they can also use languages like Flash, HTML, or any other type of code that a modern web browser will run.

XSS is a broad category of threat. As explained below, there are several different types of XSS attacks, and threat actors who use XSS may have a variety of end goals in mind. However, what all XSS attacks share in common is that they are enabled by flaws in either the code or configuration of websites that make it possible for threat actors to inject malicious scripts into sites that users deem trustworthy.

Cross-site scripting is so-called because, in most cases, XSS attacks happen when a script hosted on one website or server (typically, a server that attackers control) is injected into a different site that users access. However, this is not always the case. In persistent XSS attacks (which are described in detail below), only a single website is involved. Thus, the term "cross-site scripting" is slightly misleading; XSS attacks don't necessarily involve spreading scripts across distinct websites.

Different Types of Cross-Site Scripting

Cybersecurity researchers have identified three main types of XSS attacks. They are distinguished primarily by the attack technique. The attacks are also different in terms of how easy they are to execute, and how difficult they are to detect.

Persistent XSS

In a persistent XSS attack, attackers store malicious code directly on a compromised website. Hence why it's called "persistent XSS": The malicious script is persistent because it lives on a compromised website.

To execute a persistent XSS attack, attackers have to find a vulnerability inside a website or web server that allows them to upload their malicious code. For example, they might identify an input validation flaw on a content management system (CMS) platform that allows them to insert malicious code into an input box when they are creating comments in order to upload it to the server. If the comment function is available publicly, anyone could exploit the flaw to insert malicious code onto the server.

Once the code has been uploaded, it can be executed every time a user visits the website or web page that it affects. Thus, persistent XSS attacks are particularly dangerous because they don't require users to make mistakes. The only thing a user has to do to be harmed by a persistent XSS attack is to visit a compromised website. That said, these XSS attacks are relatively easy to prevent by validating input to detect malicious code.

Non-persistent XSS

In non-persistent XSS attacks, which are sometimes also called reflected XSS attacks, users are "tricked" into running malicious code on their browsers. From the user's perspective, the code appears to be stored on a website that the user trusts, but in reality it's a malicious script that can be executed locally in a browser.

This XSS attack technique is called non-persistent or reflected because the malicious code is never stored persistently on the affected website. Instead, it's "reflected" from the user's browsers to the website and then back to the browser.

Related: What Is Reflected XSS?

The most common way to execute a non-persistent XSS attack is to get users to click a link that contains malicious code inside its URL. For example, attackers might create a URL like the following:

xss_text

This is a simplistic example in which the malicious code (which wouldn't actually run in this case) is plainly visible from actually looking at the URL. In real-world non-persistent XSS attacks, the malicious code is often obfuscated in a way that makes it harder for users (or security tools they may have running on their systems) to detect the malicious script. For example, the malicious code may be represented in hexadecimal form rather than plain text to make it harder to detect.

Non-persistent XSS attacks don't pose quite as much danger as persistent XSS attacks because non-persistent XSS requires users to make a mistake — like clicking on a malicious link — rather than simply visiting a website. However, non-persistent attacks are easier for threat actors to execute because they don't need to find flaws in websites. All they have to do is create hyperlinks that contain malicious code, then display the links on a webpage, email, text message, or other medium where users might view and click on them.

DOM-Based XSS

In DOM-based XSS attacks, attackers modify the configuration of a web page's Document Object Model, or DOM, in order to run malicious code.

To perform a DOM-based attack, attackers must find a JavaScript property, such as document.URL, into which they can inject malicious input. The input is then executed when the web page is rendered.

DOM-based attacks are the most complex type of XSS attack to execute, and they work only for websites or web applications with specific DOM environments. However, the attraction of a DOM attack from a threat actor's perspective is that this type of attack is very hard to detect because the malicious code never passes through the website or web server. As a result, security tools running on the server, as well as tools that monitor network traffic, can't see the malicious script. Only security software running locally (in other words, on the "client side") has the potential ability to detect the malicious code — and even then, there is no guarantee that client-side tools will properly recognize DOM-based cross-site scripting.

Consequences of Cross-Site Scripting

Because cross-site scripting makes it possible for attackers to run scripts of their choosing on the computers of affected users, there is virtually no limit to the potential consequences of XSS attacks. That said, common effects of XSS attacks include:

Poor site performance: In general, XSS attacks have the consequence of degrading website performance because they consume resources and make pages slower to load. Thus, even if an XSS attack does not result in user impersonation or data theft, it will still negatively impact users by wasting resources and disrupting the user experience.

Best Practices for Preventing Cross-Site Scripting

Since there are multiple types of cross-site scripting attacks, protecting against them requires the employment of several best practices that mitigate the risk of successful XSS breaches:

Conclusion

Cross-site scripting attacks come in many forms, and they can have wide-ranging consequences. In order to protect against these risks, developers and admins must think holistically about how they filter user input, how they manage their software, and how they leverage any tools available on users' devices to mitigate the risk of XSS attacks.