Cross-Site Scripting (XSS)
Introduction
Cross-Site Scripting, usually shortened to XSS, is a web security vulnerability that lets an attacker get their own script running inside another user's browser, using a legitimate website as the delivery mechanism. The website itself isn't directly compromised — it's tricked into serving someone else's code to its own visitors.
What XSS Does
Normally, a browser trusts whatever a website sends it and runs any script included in the page. XSS abuses that trust: if a site takes user-supplied input and displays it back on a page without properly neutralizing it first, an attacker can slip in a script instead of ordinary text, and the browser will execute it as if the site itself had written it.
Why It Matters
A successful XSS attack can steal session cookies, letting an attacker impersonate a logged-in user.
It can redirect victims to malicious sites or quietly modify what they see on a page.
It can be used to capture keystrokes, steal form data, or trigger further attacks.
It remains one of the most common vulnerabilities found in real-world web applications, which is why it's a standard topic in web security training.
The Three Main Types
Reflected XSS
The malicious script is part of the request itself — often embedded in a URL or a search field — and the server immediately reflects it back in the response. It only affects a user if they're tricked into clicking a specially crafted link, since the payload isn't stored anywhere; it has to be delivered fresh each time.
Stored XSS
Here, the malicious script gets saved on the server itself, for example inside a comment, a profile field, or a message. Every user who later views that stored content unknowingly runs the script, since it's no longer something the attacker needs to deliver individually — the vulnerable page serves it automatically.
DOM-Based XSS
This variant happens entirely within the browser. Instead of the server inserting untrusted data into the page, client-side JavaScript itself reads data from somewhere the user can influence — such as the URL fragment — and writes it directly into the page structure (the DOM) without sanitizing it first.
A Simple Illustration
To understand the underlying mechanism, imagine a page that takes a name typed into a search box and echoes it back with a message like "Results for: [name]". If the page inserts that name directly into the HTML without escaping special characters, then instead of a name, an attacker could submit something that the browser interprets as an executable script tag rather than plain text. The browser has no way to tell the difference between "text the site meant to display" and "code the site meant to run" — it simply executes whatever looks like a script.
Why This Happens
At its core, XSS comes down to one root cause: mixing untrusted input with executable output without transforming it first. A web page is built out of HTML, and HTML doesn't distinguish between data and code — anything that looks like a tag or a script block gets treated as one, unless the application actively converts special characters like < and > into their safe, printable equivalents before inserting user input into the page.
Defending Against XSS
Output encoding — Before displaying user-supplied data anywhere in HTML, that data should be encoded so that characters like <, >, and " are converted into harmless text equivalents rather than being interpreted as markup.
Input validation — Restricting what kind of input is accepted in the first place (for example, only allowing letters and numbers in a username field) reduces the range of possible attacks, though it isn't a complete substitute for proper output encoding.
Content Security Policy (CSP) — A CSP header lets a website tell the browser which sources of scripts it trusts, so even if malicious script content slips through, the browser can be instructed to refuse to run anything from an untrusted source.
HttpOnly cookies — Marking sensitive cookies (like session tokens) as HttpOnly prevents JavaScript from reading them at all, which limits the damage even if a script does manage to run on the page.
Using modern frameworks correctly — Many modern web frameworks automatically escape data by default when rendering templates, which closes off a large share of XSS risk as long as that default behavior isn't deliberately bypassed.
Regular security testing — Since XSS can hide in unexpected corners of an application, routine code review and automated scanning tools are commonly used to catch these issues before an application goes live.
Notes
XSS lets an attacker run their own script in another user's browser by exploiting a website's failure to properly handle untrusted input.
Reflected XSS requires a fresh, one-time delivery (like a malicious link); stored XSS persists on the server and affects every visitor automatically; DOM-based XSS happens entirely within client-side JavaScript.
The root cause is almost always a failure to properly encode untrusted data before inserting it into a page.
Defenses include output encoding, input validation, Content Security Policy, HttpOnly cookies, and relying on frameworks that escape data safely by default.
