What Is Cross-site Scripting and How to Prevent It

Cross-site scripting is a vulnerability in web security. It is often abbreviated XSS.

In vulnerable sites and apps, user interactions with the application may be compromised by a threat actor, commonly referred to as an attacker. XSS is a technique threat actors use to evade controls such as the same origin policy, which modern browsers rely on to restrict data access between applications or websites.

Under an XSS attack, an attacker may be capable of impersonating a user, which would allow them to perform any of the same actions a legitimate user would perform. It would also allow the attacker to access the user’s private information.

If an attacker gains access to a user with privileged access to a website or application, the attacker may cause more damage by altering how it functions and stealing its data.

What is a Cross-site Scripting Attack?

An XSS attack is an attack that relies on malicious script injected by an attacker to be executed client-side by a user's browser, sometimes referred to as the payload.

With XSS, an attacker can essentially leverage a vulnerable website or app into a staging area to deliver malicious code (or payload) into the user’s browser. When the user visits the affected website or application, a script is executed, which allows the attacker to wreak havoc on that interaction.

Types of Cross-site Scripting Attacks

There are three main classifications of XXS attacks: reflected XSS, stored XSS, and DOM-based XSS.

Reflected XSS - This is where the payload is “reflected” from a web application into the user browser. The code is usually activated via a link in a phishing email or sent via social media as a private message. The link leads to a vulnerable site that allows the script to be executed.
Stored XSS - In a stored XSS attack, the payload of malicious script is typically stored in the web server database of the affected website and injected into a web application when a user loads a page from the web server.
DOM-based XSS - Here, the problem lies in the client-side code (as opposed to the server-side code). The attack is enabled by modifying the document object model (DOM) in the user’s browser, making the client-side script run differently than it should.

Also worth mentioning are application penetration testers, or simply pen testers. Pen testers conduct simulated cyberattacks on an organization’s computer systems or networks. These are legitimate, authorized tests that actually help identify cybersecurity vulnerabilities so that they can be addressed before malicious attackers find and exploit them.

What Can an Attacker Do With a Cross-site Scripting Attack?

Typically, a successful XSS attack allows a threat actor to masquerade as a real user. This is dangerous because in the case of a high-level user with restricted access, it could allow the attacker to:

Make any and all changes to the application or website as that user
Read any data the impersonated user is authorized to access
Steal that user’s login and password
Tamper with, vandalize, or deface the website or app
Infect the site or app with trojan ability

How Cross-site Scripting Works

An XXS attack usually consists of two steps. In order for the first step to happen, the website identified by the attacker as the vehicle for the attack needs to be one where user input is allowed (i.e., an online message board). The malicious string of code inserted by the attacker will be treated by the victim’s browser as legitimate source code.

The attacker finds a way to inject the payload into the browser of the victimized user via a webpage visited by the victim.
Once the payload is injected into the webpage, the user must visit that page. In cases where the XSS attack is targeted at a particular victim or victims, the attacker may use a phishing scheme or social engineering to deliver the malicious URL they want them to visit. These schemes play a key role in account takeover fraud (ATO), leading to further problems for victimized users.

Who Is Most Vulnerable to a Cross-site Scripting Attack?

Websites or applications that are especially vulnerable to XSS attacks include message boards, discussion forums, or websites that allow users to make comments. People who own and operate these pages should be extra vigilant about security.

Any website or application that uses unfiltered or potentially unsanitized user input to generate an improperly escaped output could be particularly vulnerable to XSS attacks.

XSS attacks are most common in JavaScript, since this language forms the code foundation of most web experiences. However, they can also be conducted via older Flash or ActiveX, and also VBScript and CSS.

Common Vulnerabilities Exploited by XSS Attackers

Here is a list of vectors an XSS attacker might choose to exploit, for various reasons. This is not an exhaustive list, just several of the most common targets for inserting malicious code.

JavaScript events
<script> tags
<embed> tags
<img> tags
<body> tags
<iframe> tags
<link> tags
<input> tags
<div> tags
<table> tags
<object> tags

How to Prevent a Cross-site Scripting Attack

Despite how harmful an XSS attack can be, XSS vulnerabilities are among the most common weaknesses in web applications. The Open Web Application Security Project (OWASP) lists injection attacks, including XSS, as number three in their Top Ten Web Application Security Risks.

Preventing XSS attacks isn’t easy, but it is possible. The prevention techniques you use will depend on your programming framework, the type of vulnerability that affects you, and how user inputs are used by your application. There are, however, some basic steps that are more universal in preventing XSS attacks.

Staff awareness and training
Make sure that anyone who plays a role in building and maintaining your web applications is well aware of the dangers of XSS vulnerabilities. This would include not only developers but also system administrators, DevOps, and QA personnel. QA testing, commission independent pen testing, and dynamic application testing should be considered. Frequent and thorough testing is critical.
Filtering all input at the point of receipt
Avoid HTML inputs where possible. Where they cannot be avoided, each input must be as thoroughly sanitized as possible. Even if it’s from an authenticated user, any data received from a user or browser should not be trusted. Operate under the assumption that all data is public input that contains malicious code.

As a security architecture model that verifies and authenticates each and every user and device before allowing them to access apps and other assets, a zero trust approach can help decrease your XSS vulnerability. Think of it as moving away from a “trust, but verify” model to a “never trust, always verify” model.
Encoding or escaping all data on output
Anytime user input is part of HTML output, there is an increased XSS risk. You can reduce the risk by encoding the output in a way that prevents it from being understood as active content. Depending on the context of the output, this could require combined encoding using HTML, JavaScript, URL, and CSS. This technique is also commonly referred to as output escaping.
Ensuring appropriate response headers
Using Content-Type and X-Content-Type-Options headers can help you keep XSS from being injected into HTTP responses that shouldn’t contain any JavaScript or HTML. These headers can help browsers execute your intended response.
Enacting content security policy
After doing all of the above, you can use content security policy (CSP) as a final safety net. CSP allows website owners to standardize and explicitly declare approved content origins, script blocks, and script files that browsers are allowed to load onto their site. It may help curtail the severity of any remaining XSS vulnerabilities.

Now that you know how dangerous—and how common—XSS is, it should be pretty clear that access control alone is inadequate for preventing XSS attacks.

DevOps and IT security teams should take a comprehensive approach to guarding against all API threats. To learn more about the crucial steps these teams should be taking, read 12 Things DevOps and IT Security Must Do to Protect APIs.