Android WebView UXSS shows how outbound callbacks create takeover risk

At a glance

What this is: Novee’s research shows that Android WebView UXSS can emerge from outbound native-to-web callbacks as well as inbound bridge exposure, and that one pattern scaled across 20 apps into 12 findings and an account takeover.

Why it matters: For IAM, PAM, and application security teams, this matters because a WebView-origin flaw can hijack authenticated sessions, bypass CSP, and expose identity-bearing tokens even when the obvious bridge checks look sound.

By the numbers:

• Then, we formalized the patterns and pointed Novee at 20 Android apps.

👉 Read Novee's analysis of Android WebView UXSS and account takeover paths

Context

Android WebView is a common control plane for embedded browsing, in-app checkout, and hybrid app workflows, which makes it an identity and session boundary as much as a UI component. The security gap is that many teams validate who can call native bridges, but do not re-check what page receives the callback after navigation changes. That mismatch is why Android WebView UXSS can turn into session hijacking, token exposure, and account takeover.

The article’s core finding is that the risky moment is often not the initial call, but the delayed native reply that lands on whichever origin is loaded at execution time. That creates a governance problem for mobile IAM and app teams: origin checks done at call time do not protect the session if the page changes before the callback runs. This pattern is common enough that it should be treated as a repeatable control failure, not a one-off bug.

Key questions

Q: What breaks when native WebView callbacks are not revalidated at use time?

A: The origin can change after the initial check, so the callback executes on a different document than the one that requested it. In practice, that can turn a benign bridge reply into script execution on an authenticated page, which exposes sessions, DOM state, and account functions.

Q: Why do Android WebView UXSS bugs become account takeover risks so quickly?

A: Because WebView often hosts already-authenticated sessions inside banks, mail, commerce, and enterprise apps. If an attacker can execute script on that origin, they can read or manipulate session state, trigger actions as the user, and move from code execution to identity compromise.

Q: What do security teams get wrong about evaluating WebView bridge safety?

A: They often focus on who can call the bridge and overlook where the reply lands after asynchronous work. That misses the outbound path, which is where delayed callbacks, navigation changes, and persistent listeners can create a practical UXSS sink.

Q: How should mobile teams reduce UXSS risk in WebView-based apps?

A: They should treat navigation, intent handling, and callback lifecycles as one control surface. That means validating URL schemes, expiring callback state on page change, and testing the app alongside nearby Android components that influence scheme resolution and deep-link handling.

Technical breakdown

Why outbound WebView callbacks become a UXSS sink

Universal Cross-Site Scripting in Android WebView happens when native code executes JavaScript into the currently loaded page without re-validating the origin at use time. The dangerous APIs are evaluateJavascript() and loadUrl("javascript:...") because they act on whatever document is live when the callback fires. If a page navigates during an async gap, the callback can land on a different origin than the one that initiated the request. That turns a safe-looking bridge reply into code execution on a victim site, including trusted domains and authenticated sessions.

Practical implication: bind callbacks to the originating document and clear pending state on navigation changes.

How TOCTOU on origin turns async work into account takeover

The article describes a time-of-check, time-of-use race on origin. The application checks the caller or page before starting work, then performs asynchronous work such as dialogs, I/O, or event listeners, and only later emits JavaScript back into the WebView. Because the origin can change during that gap, the eventual callback may execute on the wrong page. This is not necessarily a microsecond race. User actions like app switching, dialog dismissal, or navigation commit can be enough to move the WebView before the native reply lands.

Practical implication: re-validate origin immediately before every callback execution, not only when the bridge method is invoked.

Why deep links and javascript: URIs widen the attack surface

The second family of findings uses navigation and intent handling rather than bridge callbacks. If an app accepts javascript: URIs, browser_fallback_url values, or deep link parameters without strict scheme validation, a crafted link can force script execution in the current tab. The article shows that these paths can bypass Content Security Policy because the JavaScript runs below the page’s own controls. In mobile ecosystems, cross-app composition makes this worse because one app’s manifest or intent filter can change another app’s exposure.

Practical implication: reject javascript: schemes and validate every browser_fallback_url and deep-link target before passing it to loadUrl().

Threat narrative

Attacker objective: The attacker wants to execute script on a trusted origin inside WebView so they can hijack sessions, extract identity-bearing data, and take over accounts.

1. Entry occurs when an attacker delivers a crafted link, deep link, or page that reaches a vulnerable Android WebView or browser intent path.
2. Credential access follows when the attacker swaps the loaded page before a delayed native callback executes, letting JavaScript run against an authenticated origin.
3. Impact occurs when the injected script steals session data, manipulates trusted content, or enables full account takeover on the victim service.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• JetBrains GitHub plugin token exposure — CVE-2024-37051 in JetBrains IntelliJ GitHub plugin exposed GitHub access tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Outbound callback trust is the real WebView governance gap. Most mobile app teams still concentrate on inbound bridge checks, but this research shows the more durable failure sits in the reply path. If native code can emit JavaScript after a navigation change, the origin decision has already gone stale. That is a control-design problem, not just a coding defect, and practitioners should treat outbound callback validation as a separate security domain.

TOCTOU on origin is the named concept this research should anchor. The article demonstrates that the page can change between validation and execution, which means the security boundary is temporal as well as spatial. That matters for identity security because authenticated sessions, cookies, and account state are attached to the current document, not the original caller. Teams that do not model document drift will keep missing the same class of UXSS.

Mobile app isolation assumptions break down once WebView and deep links interact. The cross-app composition findings show that one installed app can widen another app’s exposure through manifest declarations and intent handling. This is a governance issue for platform owners, not only app developers, because the effective attack surface depends on the whole device ecosystem. Security reviews should therefore include the surrounding Android environment, not just the target APK.

WebView UXSS is an identity issue because it lands on authenticated origins. The payload is rarely arbitrary script in the abstract. It is script execution against a bank, mailbox, intranet, or commerce session that already trusts the browser context. That makes the control objective session integrity, not simply code cleanliness, and it aligns with the same identity protection principles that govern phishing-resistant access and token containment.

Automation changes the economics of mobile bug discovery. Once a pattern is formalized, it can be replayed across large app sets and surface risks that manual review would miss. That shifts the security conversation from isolated findings to repeated control failure, which is the right lens for platform governance. Practitioners should assume that if one WebView callback path is wrong, others are likely wrong in the same way.

What this signals

Android teams should expect the same class of failure to appear wherever asynchronous native code meets a browser context. The key governance lesson is not just that WebView is risky, but that origin must be enforced at the moment of execution, not only at the moment of request. For broader context on how identity failures create attack surface, see [The 52 NHI breaches Report](https://nhimg.org/52-non-human-identity-breaches) and the [Ultimate Guide to NHIs , Key Challenges and Risks](https://nhimg.org/the-ultimate-guide-to-non-human-identities#key-challenges-and-risks).

TOCTOU on origin: this is the control gap mobile security programmes need to name, measure, and test for. Once that concept is operationalised, teams can build detection and validation around page lifecycle changes, callback persistence, and scheme misuse instead of relying on code review alone. For offensive testing patterns that map well to this problem space, the [OWASP NHI Top 10](https://nhimg.org/complete-guide-to-the-2026-owasp-top-10-risks-for-agentic-applications) is a useful adjacent reference.

As mobile apps increasingly embed identity flows, session recovery, and commerce actions inside WebView, the boundary between application security and identity governance gets thinner. That means IAM and appsec teams should align on browser context controls, not treat them as separate review tracks. The practical signal is simple: if a callback can outlive the page that requested it, the trust model is already too loose.

For practitioners

• Audit outbound WebView reply paths Trace every evaluateJavascript() and loadUrl("javascript:...") call back to the originating document, and require a fresh origin check before execution. Clear stored callbacks when onPageStarted or equivalent navigation events fire.
• Block unsafe scheme handling in deep links Reject javascript: schemes, validate browser_fallback_url values, and whitelist only http and https before any URL reaches loadUrl(). Treat intent extras and URL parameters as untrusted input until scheme validation completes.
• Bind callback state to page lifecycle Store callback identifiers in a way that expires with the page session, not the app process, and drop them when the active document changes. This prevents delayed replies from landing on a different origin after navigation.
• Test cross-app composition on Android Assess the device ecosystem, not just the target APK. Include browsers, preinstalled apps, and unusual intent filters in the test matrix because another installed app can change how javascript: and deep links are resolved.

Key takeaways

• Android WebView UXSS is often a callback-lifecycle problem, not just a bridge-authentication problem.
• The research scaled one manually found pattern into 12 additional findings across 20 apps, which is strong evidence of repeatable control failure.
• Revalidating origin at execution time, expiring callback state on navigation, and rejecting unsafe URL schemes are the controls that matter most here.

Key terms

• Universal Cross-Site Scripting: Universal Cross-Site Scripting is a flaw that lets an attacker execute script on an origin of their choosing inside a trusted browser context. In Android WebView, that means the application’s rendering layer becomes the problem, allowing account hijacking, session theft, and content manipulation on otherwise trusted sites.
• Time-of-Check, Time-of-Use race on origin: A Time-of-Check, Time-of-Use race on origin occurs when a page is validated at one moment and the script is executed later against a different page. In WebView, asynchronous callbacks, navigation changes, and persistent listeners can make the checked origin and the executed origin diverge.
• Browser fallback URL: A browser fallback URL is the alternate destination used when an Android intent cannot open its intended target application. If it is not strictly validated, it can become a script execution path or a navigation sink, especially when apps accept javascript: or other unsafe schemes.
• WebView callback lifecycle: WebView callback lifecycle is the set of rules governing how long a callback remains valid, when it should be discarded, and which page is allowed to receive it. Treating it as a security boundary prevents delayed native replies from being delivered to the wrong origin after navigation.

What's in the full article

Novee's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step reverse-engineering notes showing how the first seven UXSS findings were derived from WebView bridge behaviour.
• Pseudocode and exploit flow examples for async callbacks, persistent listeners, and navigation-based origin swapping.
• Detailed Android intent and manifest conditions that make javascript: URIs and browser fallback paths exploitable.
• The account takeover chain in the e-commerce app, including the regex mistake that widened bridge access.

👉 The full Novee post covers exploit patterns, Android edge cases, and remediation examples in detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to connect identity control failures to real-world attack paths across modern systems.