Every web browser is both a display engine and a JavaScript runtime. When it renders a page, it does two things: it parses HTML to decide what to draw on screen, and it executes any JavaScript it finds to make the page interactive. Almost every modern website relies on JavaScript — from dropdown menus, form validation, chat widgets, and more.
Cross-Site Scripting (XSS) is a vulnerability that exploits this dual nature. It occurs when a website includes text submitted by a user directly in a page without first making the text safe. When the browser later reads that page, it cannot tell the difference between the original developer's JavaScript and code that an attacker slipped in through a form or URL. It executes both.
Why this is not just an inconvenience
You might think: "It's just JavaScript — how bad can it be?" In practice, very bad.
JavaScript running in a page has access to everything the user can see and do on that page. A script injected by an attacker can:
- Steal the session cookie — that cookie is how the website recognises the user as logged in. Send it to a remote server and the attacker can impersonate the victim without ever knowing their password.
- Record keystrokes — silently capture every character the victim types, including passwords and credit card numbers.
- Redirect the browser — send the user to a convincing fake login page that collects their credentials.
- Submit requests — perform any action the logged-in user could perform (send messages, transfer money, change their email address) without them realising it.
XSS is ranked A03:2021 — Injection in the OWASP Top 10, making it one of the most critical and prevalent vulnerabilities in web applications.
The three forms of XSS
Researchers have identified three distinct patterns, each with a different mechanism:
| Type | Where the payload lives | Who is affected |
|---|---|---|
| Reflected | In the URL, echoed in the server's response | Only the user who clicks the crafted link |
| Stored | Persisted in a database, served to every visitor | All users who view the infected content |
| DOM-based | Read from the URL by client-side JS only; server never sees it | Only the user who clicks the crafted link |
In this lesson you will exploit all three inside a purpose-built practice application called EchoChamber — a fictional community web app deliberately built with security flaws so you can learn safely.
What you will do
- Execute a Reflected XSS attack by injecting a payload into EchoChamber's search feature.
- Execute a Stored XSS attack by posting a malicious comment that runs code for any visitor — and capture the challenge flag.
- Execute a DOM-based XSS attack via the profile greeting feature.
- Submit the challenge flag and complete a short quiz on prevention.
Nothing you do here affects any real system. All vulnerable code is sandboxed in this educational environment.