What Is Cross-Site Scripting (XSS) & How To Prevent It

Have you ever found yourself clicking on a sketchy link from a suspicious looking email or a shortened URL from your social feed? We've all been there. Sometimes your click-happy fingers respond to muscle memory in that split second before your brain screams, "Don't click that link, it's a phishing scam..."

These days, even your grandparents are wise to the Nigerian prince email scams, but hacker tactics are ever-evolving. We're all vulnerable to cyber attacks, and one of the most common tactics is cross-site scripting, otherwise known as "XSS." Cross-site scripting is so common that even PayPal, Google, and Facebook have been its victims. In fact, XSS is so widespread, it has made an appearance in OWASP's Most Critical Web Application Security Risk report since its first year of publication in 2003.

So what is cross-site scripting, how is it used, and more importantly, how can you prevent it?

What Is Cross-Site Scripting (XSS)?

Cross-site scripting is a method bad actors use to exploit communications between users and applications. When attackers succeed at finding vulnerabilities, they can use web applications to send malicious scripts to another end user. Attackers can then impersonate users to gain access to sensitive data. In worst case scenarios, when users have privileged access to a site, an attacker can take over entire applications.

The longer an attacker has access, the more vulnerable users across a site become, and once the malicious script is executed on a user browser, the attacker has increased ability to carry out phishing, cookie theft, and keylogging. That's why it's critical to put the appropriate security measures in place—but strong security requires a deep understanding of exactly how attackers might move against you, and visibility into all suspicious behavior on your network.

Because cross-site scripting allows attackers to hide inside seemingly-legitimate communications, which are almost always going to be encrypted via the HTTPS protocol, decryption capabilities are absolutely crucial in spotting these attacks and others.

Let's take a look at a few of the ways bad actors use cross-site scripting, and then we'll outline defensive strategies you can use to protect your applications.

How Do Attackers Use Cross-Site Scripting?

There are three primary forms of cross-site scripting. Reflected XSS occurs when malicious script is sent from the current HTTP request. Stored (or persistent) XSS occurs when malicious script is sent from the website's database. Document Object Model (or DOM) based XSS occurs when the vulnerability is on client-side code instead of server-side.

Reflected XSS

In a reflected XSS attack, a user unknowingly requests malicious javascript code from a website. When a response gets sent back from the website, it includes a snippet of malicious javascript. These attacks can be particularly successful in situations where the attacker uses URL shorteners to hide their malicious code from users. If you have ever seen content pop up on your social media feed that lacks context, includes a shortened URL, or looks out of character for the person posting it, you may have come across a bad guy behind the scenes.

Stored (Persistent) XSS

In a stored (or persistent) XSS attack, it's not the application that's the target, but its users. As an example, attackers can trick users by placing malicious code on message boards or blog comment fields. Every time a user views an infected page, it gets transmitted to the victim's browser in the form of the malicious javascript file.

DOM-Based XSS

A Document Object Model (DOM) is an API that defines the logical structure of HTML and XML documents. The DOM represents the page so programs can change the document content, style and structure. DOM-based attacks occur when a web app writes data to the DOM before proper data sanitization occurs. If an attacker manages to modify the DOM environment with a malicious payload, the client-side code will execute that payload when the compromised script runs. Unlike request or response models of XSS, DOM-based attacks can be complex to troubleshoot because they involve in-depth analysis of code flow.

How To Prevent Cross-Site Scripting

There are lots of ways to protect against cross-site scripting, but for our purposes, we'll focus on three examples: sanitizing user input, validating user input, and utilization of a content security policy. (For a piece of more in-depth information, go to the OWASP Cross Site Scripting Prevention Cheat Sheet.)

Sanitize User Input

Sanitizing user input such as GET requests and cookies will immediately put you in a better place against XSS attacks. This method of defense is helpful for sites that allow HTML markup that may need a data scrub to eliminate unacceptable or harmful user input.

Validate User Input

Input validation (or data validation) is the process of testing all user or application inputs and blocks inaccurately formed data from entering an information system. This OWASP cheat sheet maintains that user input validation isn't a silver-bullet solution for XSS prevention, but it can help by preventing users from inserting special characters into dropdown fields in forms.

Utilize a Content Security Policy

A content security policy is a standard that helps define rules to block malicious content by only allowing particular kinds of content from safe sources. A content security system instructs a user's browser only to allow content served from a specific domain.

When Prevention Isn't Enough

Security analysts must be proactive in securing their systems to stay on top of detecting malicious code, but there's only one way to confidently manage the risk of an XSS attack: guaranteeing that your security team has the ability to detect strange behavior in what might, on the surface, look like legitimate traffic.

That means a.) close collaboration between all the groups who know your attack surface well, and b.) a monitoring tool that supports secure, scalable decryption and analysis of encrypted traffic.