XSS vulnerabilities remain a durable path to session hijacking

At a glance

What this is: Probely argues that XSS still persists as a high-impact web application risk because injected scripts can execute in the browser and enable session theft, phishing, and unauthorized actions.

Why it matters: For IAM and application security teams, XSS matters because it turns a browser session into an identity takeover path, undermining authentication assurance, session controls, and trust in client-side state.

By the numbers:

• Web applications are involved in 26% of all breaches, according to Probely.

Context

Cross-site scripting is a web application weakness that lets attacker-controlled script run inside a victim's browser context. The security problem is not only finding the flaw, but preventing untrusted input from becoming executable output or mutable client-side state in the first place. For IAM and identity-led programmes, that matters because the browser session is often the last trust boundary before an account is effectively taken over.

Probely frames XSS as a durable attack path because it can hijack sessions, redirect users to phishing pages, and trigger actions the user never intended. The article also distinguishes stored, reflected, and DOM-based XSS, which means teams need different detection and prevention controls depending on whether the payload persists on the server, reflects through a request, or is assembled in the browser.

Key questions

Q: What breaks when XSS is not stopped before the browser renders it?

A: When XSS reaches the browser, the application stops treating user data as content and starts executing attacker logic in an authenticated session. That can expose cookies, session tokens, page state, and protected actions. The failure is not only technical execution. It is loss of trust in the browser as a safe boundary for the user account.

Q: Why does XSS remain risky even when users must already be authenticated?

A: XSS is dangerous after login because the attacker operates inside the victim’s trusted browser session. If scripts can read tokens, change page actions, or redirect traffic, authentication stops being a boundary and becomes an asset the attacker can abuse. That is why session protection and output controls both matter.

Q: What do security teams get wrong about XSS in complex browser applications?

A: They often focus on payload filtering and miss the real issue, which is trust assignment across components. If a query parameter, message event, or annotation field can influence a DOM sink after re-rendering, the exploit will usually survive superficial sanitisation. Strong controls come from origin validation, output encoding, and eliminating unsafe rendering patterns.

Q: Should teams prioritise DOM-based XSS or stored XSS first?

A: Teams should prioritise whichever path has the widest blast radius and the most sensitive session context, not just the easiest flaw to find. Stored XSS usually deserves immediate attention because it can affect many users over time, while DOM-based XSS becomes critical when client-side rendering drives privileged actions or sensitive data exposure.

Technical breakdown

How XSS turns a browser session into identity abuse

XSS is not just script injection. It is a way to make the victim's browser run attacker-controlled code inside an authenticated session, which collapses the boundary between user intent and application state. Once the script executes, it can read or manipulate page content, force requests, or harvest session material such as cookies or tokens where browser protections and application design allow it. That is why XSS often behaves like an identity compromise, not just a content flaw. The key technical failure is that untrusted input reaches rendering or client-side logic without being treated as hostile data.

Practical implication: Treat browser-executed script as a session integrity problem, not only a code-quality issue.

Stored, reflected, and DOM-based XSS fail at different control points

Stored XSS lives in durable application data, so the payload survives until the server-side content is cleaned or removed. Reflected XSS depends on a crafted request or URL that is immediately echoed back into the response, usually through social engineering. DOM-based XSS never needs the server to return malicious markup at all, because client-side code takes unsafe input and writes it into the DOM. These three forms require different detection logic, but they share the same root cause: data is trusted before it has been normalised, encoded, or validated for the context in which it will be used.

Practical implication: Map each input and output path so you can apply the right test and control at the correct boundary.

Why validation, sanitization, and output encoding all matter

Input validation, sanitization, and output encoding solve different parts of the same problem. Validation checks whether input fits an expected shape. Sanitization removes or neutralises dangerous content. Output encoding ensures that even if hostile data survives earlier stages, the browser treats it as text rather than executable code in HTML or URL contexts. Relying on only one of these controls leaves gaps, especially in applications that combine server-rendered pages with client-side rendering. The strongest defence is contextual handling of untrusted data across the full request-response and DOM lifecycle.

Practical implication: Use layered controls so hostile input cannot survive into a browser-executable context.

Threat narrative

Attacker objective: The attacker wants to execute code in the victim's browser to hijack an active session and use that trust to steal data or perform unauthorized actions.

1. Entry occurs when an attacker places malicious script in stored content, crafts a reflected link, or abuses unsafe client-side handling of URL data.
2. Credential or session material is exposed when the script runs in the authenticated browser context and interacts with cookies, tokens, or page state.
3. Escalation follows when the attacker uses that trusted browser session to submit actions, redirect the user, or access data that should have stayed protected.
4. Impact is unauthorized account activity, session hijacking, phishing redirection, data theft, or website defacement.

Breaches seen in the wild

• McKinsey AI platform breach: McKinsey AI platform hack exposed 46M chats and sensitive data.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

XSS is a session integrity problem, not just an input-handling bug. Once attacker-controlled code runs in an authenticated browser, the compromise reaches the trust boundary that many application teams incorrectly treat as already verified. That makes XSS especially relevant to identity programmes because it can subvert session assurance without breaking authentication itself. Practitioners should treat browser execution as an identity risk surface, not a frontend nuisance.

Contextual output handling is the control gap that matters most. The article's examples show that stored, reflected, and DOM-based XSS all exploit different trust failures, but each succeeds because untrusted data is allowed to survive into a context where the browser interprets it as code. That is a governance failure in data handling, rendering, and client-side state management. Teams should define control ownership across application, frontend, and security engineering functions.

XSS remains durable because web teams often optimise for feature delivery over execution context control. Validation, sanitization, and encoding are well-known, but they are frequently applied inconsistently across frameworks, templates, APIs, and client-side code. That inconsistency creates a persistent attack surface even in modern stacks. Practitioners should assume that a mix of server rendering and browser-side logic will keep producing XSS unless control ownership is explicit.

Probely's analysis reinforces a broader application-security pattern: identity abuse often begins as content abuse. The attacker does not need to break authentication when the application will execute attacker-controlled script inside a trusted browser session. That makes XSS an important bridge topic between application security and IAM, especially where sessions confer access to sensitive personal or financial data. Practitioners should align XSS testing with session-hardening and account-protection controls.

Session hijacking is the named concept teams should track as the outcome of unresolved XSS exposure. The key issue is not merely whether a vulnerability exists, but whether the application allows hostile code to inherit authenticated user context. That concept should shape threat modelling, secure coding reviews, and remediation prioritisation. Practitioners should classify unresolved XSS by its likely session impact, not by sink location alone.

From our research library:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Session hijacking is the practical outcome to model. XSS persists because many applications still treat browser input as presentation data rather than as a potential code path. Once the script executes in the user's session, identity assurance is no longer protecting the application boundary in any meaningful way.

Contextual output encoding is the named control gap. The article points to a failure of contextual trust, not a lack of awareness about XSS itself. Teams should review where HTML, URL, and DOM contexts are created because that is where the browser stops seeing data and starts seeing instructions.

For practitioners

• Harden all output encoding paths Encode untrusted content for the exact context it will enter, including HTML, attribute, JavaScript, and URL contexts, so the browser cannot interpret data as code.
• Validate and sanitize user input at ingress Reject input that does not match expected type, length, or format, then sanitize anything that can still reach storage or rendering through comments, profiles, URLs, or form fields.
• Separate trusted templates from user-controlled content Keep user-supplied values out of executable template logic and client-side DOM insertion patterns, especially where single-page applications build pages from URL parameters or API responses.
• Test stored, reflected, and DOM-based XSS separately Use both SAST and DAST in CI/CD so you can catch server-side injection paths, reflected request handling, and browser-side DOM sinks that only fail at runtime.

Key takeaways

• XSS remains a durable attack path because malicious script can execute in a user's browser and hijack an authenticated session.
• Stored, reflected, and DOM-based XSS fail through different mechanisms, but they all exploit places where untrusted input survives into executable context.
• The most effective defence is layered control of input validation, sanitization, and context-aware output encoding across both server and client-side code.

Key terms

• Cross-Site Scripting (XSS): A web application flaw where untrusted input is rendered in a way that causes script to execute in a user’s browser. It usually appears when output encoding, templating, or input handling is inconsistent across code paths and frameworks.
• Stored Xss: Stored XSS happens when an application saves malicious script in backend content such as comments, profiles, or posts, then serves it to other users later. Because the payload persists, one successful injection can trigger repeated execution across many authenticated sessions.
• Reflected Xss: A reflected XSS flaw occurs when an application takes untrusted input from a request and immediately includes it in the response without safe encoding. The payload is not stored server-side, but it can still execute in the victim’s browser when they follow a crafted link or submit malicious input.
• Dom-based Xss: DOM-based XSS is a client-side injection flaw where browser JavaScript writes unsafe data into the page’s DOM. The server may never process the payload, which makes this class harder to catch with server-side filters alone and increases the importance of safe front-end coding patterns.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security practitioners connect identity controls to the broader trust boundaries their programmes must defend.