Learn XSS the way it's actually found — hands-on, against a live target. Work through reflected and stored Cross-Site Scripting, identify the injection context, and get past basic input filters.
Cross-Site Scripting is a vulnerability where an application takes untrusted input and places it into a page without properly encoding it for the context it lands in. The browser can no longer tell the difference between the site's own markup and the attacker's, so the injected content executes with the full privileges of that origin.
The distinction that matters most in practice is where the payload lives. Reflected XSS is echoed straight back in the response to a crafted request. Stored XSS is saved by the application and served to every user who later views the affected page — which is what turns a single injection into a persistent threat against the whole user base.
Script running in a victim's origin can reach their session state, issue authenticated requests on their behalf, and drive the application as if it were the user — without ever needing their password.
Stored XSS is served to everyone who visits the affected page. A single successful injection into shared content can reach every user who loads it, including administrators with far more privilege than the attacker.
Since the 2021 revision, Cross-Site Scripting is folded into A03:2021 – Injection in the OWASP Top 10, alongside SQL injection. The reasoning is that both share a root cause: untrusted input crossing into an interpreter — a SQL engine in one case, the browser's HTML and JavaScript parsers in the other. The impact classes below drive its severity.
| Impact | What the attacker gains | Severity |
|---|---|---|
| Session hijacking | Act within the victim's authenticated session | High |
| Stored payload delivery | Serve the injection to every viewer of a page | High |
| Credential harvesting | Render convincing fake prompts in a trusted origin | High |
| UI manipulation | Rewrite page content to mislead the user | Medium |
Cross-Site Scripting sits in an interesting middle ground for automation. A scanner can flag places where input is reflected into a response, but confirming a working XSS means understanding the exact context the payload lands in — HTML body, an attribute, a JavaScript block — because each one needs a different approach, and each one is encoded differently by any filter in the way.
Room 4 is deliberately hands-on for that reason. You find the reflection yourself, determine the context, get execution, then repeat the exercise for the stored case and work past a simple keyword filter:
Injection is a family, not a single bug. The SQL injection lab covers the other half of A03:2021 — same root cause, different interpreter.
The XSS lab is live and free to play. Find the reflection, identify the context, confirm execution, then move on to the stored case and the filter bypass.