Academy

Module 6 · Why XSS Persists — Context Is Everything 🔒

Manish Garg
Manish Garg Associate CISSP · RingSafe
April 22, 2026
4 min read

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.

🔐 Advanced Module · Pro Tier

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.

136+ modulesAll levels up to this tier
20-question quizzesUnlimited retries with explanations
Completion certificatesShareable on LinkedIn
9 more sections locked below