XSS (Cross-Site Scripting) was the first “client-side is a target” vulnerability class. In 2026, it still appears in audits because modern frameworks aren’t magic — they defend against the common cases but not the contextual ones. Understanding WHY XSS persists is more important than learning payloads that frameworks already block. Let’s focus on what keeps finding its way through.
Why this happens
HTML is a language with multiple sub-contexts. Inside a page you have: HTML element content, HTML attribute values, JavaScript code, CSS values, URL attribute values, JSON inside a script tag. Each context has its own escape rules. React, Angular, Vue escape “HTML element content” by default (good — stops 80% of XSS). But the moment you render into a different context — a URL, a CSS value, a JSON-in-script — that default escaping is wrong or insufficient.
Developers think: “my framework escapes output, so I’m safe.” The truth: “my framework escapes the one context it knows about, and I’m safe in that one context only.” Every other context is a fresh decision.
Meanwhile, attackers are testing every sink. The payload that works in an element body won’t work in a URL, and vice versa. Modern XSS hunters know the contexts better than the framework authors who built the defaults.
Continue reading with Pro tier (₹4,999/year)
You've read 25% of this module. Unlock the remaining deep-dive, quiz, and every other Advanced/Expert module.