Why Code-Level Defenses Aren't Enough
How XSS gets past your existing defences
XSS doesn't need your whole application to be vulnerable. It needs one gap — and that gap is often somewhere your code-level defences can't reach.
What These Have in Common
Untrusted content, rendered in a privileged session
Read those incidents together and the same architecture appears in every one. Content nobody vetted — a support ticket, an email, a device name — is rendered inside a session that has reach: across tenants, across mailboxes, across every managed endpoint in the estate. The vulnerability is the cheap part. What turns it into a breach is where the payload lands.
The support ticket is the back door to your admin console, and your admin console is the front door to every customer.
It also answers the most common objection to any of this, which is that you don't have user-generated content. Ivanti had no forum and no ticket queue in the payload path. It had device names. Any field an untrusted system can write and a privileged human later reads is user-generated content, and most estates have far more of them than anyone has counted — log viewers, asset inventories, error dashboards, webhook payloads, filenames.
A nonce-based policy with no 'unsafe-inline' breaks the chain at the point that matters: the injected script carries no nonce, so it never executes and the session is never taken. That is the mitigation, and it is worth being straight about its limits — Google's own published material puts roughly a quarter of XSS bugs as still exploitable in an application running a strict CSP.
Which is why the reporting half is the part that pays. At Canvas, four days passed between the payload firing in a support agent's session and anyone noticing unusual API activity. A policy running in report-only on that one internal tool would have said so on day one — an inline script with no nonce is the loudest, simplest signal there is. Google's own XSS numbers are the long-run version of the same argument: cross-site scripting fell from 30% of their vulnerability reward payouts in 2018 to 4.1% in 2023.
CSP is the browser-native mechanism designed for XSS protection when code-level defences miss. The challenge is deploying and enforcing it at scale.
