Cross-Site Scripting (XSS) — Introduction
Why it matters
Web apps are widespread and complex, and Cross-Site Scripting (XSS) is one of the most common classes of flaws. XSS abuses weak or missing sanitization of user-supplied data so an attacker can get JavaScript executed in another user’s browser in the context of the vulnerable site.
What XSS is
A normal flow: the server sends HTML; the browser renders it. If the app echoes user input into the page without proper encoding or sanitization, an attacker can inject script (for example via a comment or reply). When a victim loads that page, their browser runs the attacker’s JavaScript.
Important properties:
- XSS runs in the client; it does not “hack the server” directly. Impact is on users who execute the payload.
- Direct server impact is often low, but XSS is very common, so overall risk is often framed as medium (high probability + lower direct server impact). Teams still treat it seriously: detect, fix, and prevent through design, reviews, and testing.
Risk treatment (same idea as a probability/impact matrix) includes reduce, avoid, accept, and transfer—for XSS, reduce (controls + secure dev) is the usual goal.
What attackers can do
Anything the browser can do with JavaScript in that context, for example:
- Exfiltrate session cookies (or other sensitive data the page can read) to an attacker-controlled host.
- Trigger actions as the victim via API calls the browser can make (e.g. account changes if the session is still valid).
- Misuse of the user’s machine for the attacker’s ends in the browser (e.g. cryptomining scripts, unwanted ads, UI defacement).
Limits (typical modern web):
- Payloads run in the browser’s JavaScript engine (e.g. Chrome’s V8), not as arbitrary OS-level code by themselves.
- Same-origin policies usually restrict what origins the script can talk to; the abuse is still serious inside the vulnerable app’s origin.
Escalation: A separate memory corruption or sandbox escape in the browser could, in theory, be chained with XSS so that starting from JS execution leads to code outside the sandbox. That path is rarer than “classic” XSS impact but is part of why XSS is not dismissed as “only” a client bug.
Prevalence and real examples
XSS has been exploited for many years and still appears in large products.
| Example | What happened |
|---|---|
| Samy worm (2005, MySpace) | Stored XSS spread a self-replicating profile snippet (“Samy is my hero”). ~1M+ profiles affected in about a day. Mostly a stunt, but the same class of bug could enable theft or worse. |
| TweetDeck (2014) | Researcher-triggered XSS led to a self-retweeting tweet; tens of thousands of retweets in minutes; TweetDeck taken offline briefly to patch. |
| Google Search (e.g. 2019) | XSS in search / related components (e.g. issues tied to XML handling) shows even mature surfaces miss edge cases. |
| Apache HTTP Server | Documented XSS instances have been actively exploited in some deployments (e.g. scenarios involving credential theft). |
Takeaway: XSS deserves real engineering effort for prevention and response, not only “low severity by default.”
Types of XSS (overview)
There are three main categories:
| Type | Also called | Idea |
|---|---|---|
| Stored (persistent) | Persistent XSS | Input is saved (DB, etc.) and rendered later for others—e.g. posts, comments. Often the highest impact because every viewer can be hit without a special link. |
| Reflected (non-persistent) | Reflected XSS | Input is not stored; the server reflects it into the response—e.g. search results, error messages. Usually needs tricking the victim into requesting a crafted URL or form. |
| DOM-based | Client-side XSS | Untrusted data flows into the DOM via client-side code (e.g. URL fragments, location, client routing) without the dangerous string necessarily going to the server. Still non-persistent from a storage perspective but logic is in the browser. |
Later material can drill into each type, exercises, and exploitation patterns.