XSS and OAuth combine into a modern account takeover path

At a glance

What this is: Salt’s analysis shows that modern XSS exploitation can still succeed when OAuth redirects expose credentials in the browser flow, turning a web injection issue into account takeover.

Why it matters: It matters because web teams often harden cookies and sanitisation in isolation, but identity-bearing redirects and browser trust boundaries can still create a takeover path.

Context

Cross-site scripting remains a browser execution problem, but the governance failure is broader than a single injection flaw. When application flows hand sensitive state to the browser and then route it through redirects, the security boundary shifts from one page to the entire login journey. That is where strong cookie flags and sanitisation can still leave a trust gap.

OAuth is meant to delegate authentication safely, yet it can also expose tokens or codes in places browser script can read if the flow is designed poorly. In this article, Salt shows how that gap turns a long understood web issue into a modern account takeover path, which is a familiar pattern for application security teams but still easy to underestimate.

Key questions

Q: What breaks when XSS can reach an OAuth login flow?

A: The main failure is that browser script execution can move from a content issue to an identity issue. If OAuth codes, fragments, or return URLs are exposed in a script-readable path, the attacker may capture or replay authentication material and take over the account. The risk is not the script alone, but the combination of script execution and exposed auth artefacts.

Q: Why do HTTP-only cookies not stop modern XSS account takeover?

A: HTTP-only blocks JavaScript from reading cookie values, but it does not protect credentials exposed somewhere else in the authentication journey. If OAuth codes, fragments, or redirect targets are browser-readable, the attacker can still reuse them to impersonate the victim.

Q: How do security teams spot OAuth flows that are unsafe under XSS?

A: Look for redirects, fragments, and same-origin windows that expose authentication material to browser script. If a malicious script can inspect the return path or influence the login handoff, the flow needs redesign or stricter browser-side containment.

Q: What should teams do when browser script can reach authentication state?

A: Treat the login journey as one attack surface and tighten the places where identity material appears. Validate redirect targets, remove unnecessary browser-readable credential exposure, and test whether injected code can follow or reuse the handoff before it reaches account completion.

Technical breakdown

DOM-based XSS turns browser input into script execution

DOM-based XSS occurs when client-side code reads attacker-controlled input and writes it into a dangerous sink such as innerHTML, document.write, or a redirect target. Unlike classic server-side XSS, the vulnerable logic lives in the browser and may never be obvious from the backend. Defences such as output encoding, framework auto-escaping, and content security policy reduce exposure, but they do not eliminate unsafe client-side data flow when application code still treats query parameters as trusted state.

Practical implication: review client-side routing and parameter handling as an attack surface, not just server-rendered templates.

Why HTTP-only cookies do not end the attack path

HTTP-only cookies stop JavaScript from reading cookie values directly, which blocks the simplest XSS theft path. That control does not help if the attacker can use script execution to trigger a login or redirect workflow that surfaces other credentials in the browser URL or page context. The real control boundary is therefore the identity flow, not the cookie alone. If authentication artifacts are exposed through redirects, fragments, or window access, script execution can still convert into account compromise without touching document.cookie.

Practical implication: treat HTTP-only as a containment control, not a complete account takeover defence.

OAuth redirects can leak reusable credentials to script

OAuth login flows often move the user through an external identity provider and back to the application with an authorization code or related token material. In a browser context, those values can appear in a URL, fragment, or same-origin window that malicious script can read if an XSS is present. That creates a chaining problem: one weakness executes code, the other exposes the credential material needed to complete the takeover. The issue is not OAuth itself, but the trust assumptions in how the redirect chain is implemented and observed by the browser.

Practical implication: inspect every OAuth return path for browser-readable credential material and same-origin exposure.

Threat narrative

Attacker objective: The attacker wants to steal OAuth-derived authentication material and convert browser script execution into a usable account takeover path.

1. Entry occurs through DOM-based XSS triggered from a crafted URL that reaches client-side code paths and executes attacker-controlled JavaScript in the victim’s browser.
2. Credential access follows when the script starts or observes an OAuth login flow and reads authorization material from a browser-visible redirect or same-origin window.
3. Escalation happens when the attacker reuses the captured OAuth material to impersonate the victim in the target application.
4. Impact is full account takeover, with the ability to change settings and expose sensitive user data collected by the application.

Breaches seen in the wild

• Meta Muse agent hijack 2026: An undocumented Muse setting let local malware hijack Meta's personal AI agent, steal its authentication material and abuse user access.

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 has not gone away, but its modern risk is identity chaining. The vulnerability is no longer just script execution in isolation. When browser code can observe authentication redirects, the control failure becomes one of identity flow governance, not only input validation. Application security teams need to treat redirect paths, fragments, and window relationships as part of the trust boundary.

HTTP-only cookies solve a narrow theft path, not the takeover pattern. That control blocks one extraction method, but it does not protect credentials that are briefly exposed in browser-readable OAuth flows. This is a classic example of compensating controls failing because they were scoped to the session store rather than the full authentication journey. The practitioner takeaway is to validate where identity material is exposed, not just whether cookies are readable.

Cross-component trust is the named concept this article exposes. The browser, application, and identity provider each behave correctly on their own, yet the composite path still fails because the attacker can bridge them with script execution. That is the architectural blind spot modern web teams keep missing: secure components do not automatically create a secure end-to-end trust path.

OAuth flow design is now an application security decision, not just an identity integration task. If a redirect or window can leak authorization codes to script, the problem sits at the intersection of ASVS authentication, session management, and browser security controls. Teams should review the full login journey as a single attack surface, because the attacker only needs one readable handoff to complete the chain.

The operational lesson extends beyond this one flaw class. Any architecture that exposes short-lived credentials to a browser context deserves the same scrutiny, whether the mechanism is OAuth, SSO, or another delegated login pattern. For practitioners, the standard is simple: if a script can see it, an attacker can likely reuse it.

What this signals

Cross-component trust gaps are now the more durable web security problem. A single vulnerability may be patched, but the attack still succeeds if the application hands sensitive state across browser, identity provider, and redirect boundaries without a clear trust model. Teams should assess authentication journeys as a chain of controls, not as isolated features.

OAuth integration review belongs in application security, not only IAM. The identity team may own the protocol, but the browser implementation determines whether the browser can observe or reuse sensitive handoff material. That makes code review, redirect validation, and session design jointly relevant to account takeover risk.

For practitioners

• Harden client-side input handling Audit every browser-facing parameter for unsafe sinks such as redirects, HTML injection, and script execution paths. Prioritise code that reads query strings, hashes, or postMessage data and ensure it never reaches executable or redirectable contexts without strict allowlisting.
• Review OAuth return flows end to end Map every authorization code, token, and fragment handoff in your login journey and confirm that none of them become browser-readable to same-origin script. Validate redirect URIs, window handling, and fragment use against the actual implementation rather than the intended design.
• Treat HTTP-only as a partial control Keep HTTP-only cookies enabled, but do not assume they prevent account takeover when other credentials can surface in the browser. Pair them with flow reviews, CSP, and strict redirect validation so authentication material is not exposed through alternate paths.
• Apply browser trust boundary testing Test whether an injected script can reach same-origin windows, read redirect destinations, or influence login state during OAuth completion. Include these checks in application security testing so the review covers the full identity journey, not just classic XSS sinks.

Key takeaways

• The article shows that XSS remains dangerous when it can observe or influence OAuth handoffs, even in sites that already use common web hardening measures.
• The bypass path depends on browser-readable authentication material, so control scope must extend beyond cookies to the entire redirect and login sequence.
• Teams need to test the trust boundary between web code and identity flows, because a secure component stack can still produce an insecure end-to-end path.

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.
• OAuth Authorization Code Flow: An OAuth pattern that exchanges a temporary code for tokens instead of sending tokens directly through the browser redirect. The design reduces exposure during the authentication step and is widely used because it separates the front-channel interaction from token issuance.
• HTTP-only cookie: An HTTP-only cookie is a session cookie that browser JavaScript cannot read directly. It reduces the impact of script execution by blocking document.cookie access, but it does not stop an attacker from abusing the session through navigation, requests, or other browser-visible artifacts.
• Same-Origin Window Access: The browser rule that allows one page to interact with another window or tab when both share the same origin. In an XSS scenario, this can let injected script inspect authentication redirects or extract data from a login flow that was expected to stay transient.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and identity lifecycle. It helps security and identity practitioners strengthen how access is issued, observed, and retired across modern systems.