Android WebView UXSS shows how outbound callbacks create takeover risk

At a glance

What this is: Novee shows that Android WebView UXSS can arise from outbound callback paths, not just inbound bridge abuse, and that one manually found pattern scaled into 13 vulnerabilities across 20 apps.

Why it matters: For IAM, PAM, and mobile security teams, the lesson is that origin checks and bridge allowlists are incomplete if native code can later execute callbacks on a different page than the one that initiated them.

Context

Android WebView is the embedded browser engine that many mobile apps use for in-app content, hybrid interfaces, and identity or session flows. The security problem is not only whether the app trusts a page at call time, but whether it still trusts that same page when native code replies later. In this article, Novee shows that callback timing and navigation changes can turn a seemingly safe bridge into a takeover path.

The article sits at the intersection of mobile application security, identity governance, and session protection. A WebView callback that executes on a new origin can expose authenticated content, session state, or account actions even when the original bridge call appeared authorised. That makes outbound reply paths a governance gap, not just a code-quality issue, and the pattern appears to be typical across apps that rely on WebView bridges and asynchronous UI events.

Key questions

Q: What breaks when a WebView callback is executed after navigation changes the active page?

A: The original origin approval no longer matches the page receiving the script, so the callback can run in a different security context than the one that requested it. That can expose tokens, trusted DOM, or bridge functions to an attacker who has already moved the WebView to a victim origin.

Q: Why do outbound WebView callbacks create more risk than inbound bridge checks alone?

A: Inbound checks validate who asked for the action, but outbound callbacks decide where the response executes. If the page changes in between, the app may deliver privileged JavaScript to the wrong origin. That turns a timing gap into a trust boundary failure.

Q: What are the signs that a WebView is too broadly trusted?

A: A WebView is too broadly trusted when it can load external content without domain scoping, and when sensitive methods such as script injection or cookie access are available to pages that have not been explicitly approved. Another warning sign is relying on older patterns like UIWebView, which lacked the stronger trust controls now available in WKWebView and AppBoundDomains.

Q: How should teams respond when an Android app accepts javascript: URIs or WebView callbacks from untrusted flows?

A: They should constrain accepted schemes to http and https, re-check the active origin at execution time, and clear pending bridge state on navigation. If the app also uses authenticated bridge methods, it should be retested with deep links, fallback URLs, and cross-app intent handlers.

Technical breakdown

Why outbound WebView callbacks create origin drift

Android WebView callbacks become dangerous when native code stores a response and later injects it into the page with evaluateJavascript() or loadUrl("javascript:..."). The security decision often happens at request time, but the actual script execution happens later, after the user or application may have navigated elsewhere. That creates origin drift: the code assumes the page that initiated the request is still present, even though the active document may now be a different origin. In practice, this is a time-of-check, time-of-use problem on origin, not on data alone.

Practical implication: Treat every deferred JavaScript reply as a new trust decision and re-validate the active origin at execution time.

Why async gaps and persistent listeners widen the attack window

The article shows that the attacker does not need a microsecond race. Any asynchronous work, dialog dismissal, volume event, or listener that survives navigation can provide enough time to swap the page before the callback fires. Once the native layer replies, the callback lands wherever the WebView currently points, including a victim origin. Persistent listeners are especially risky because they survive the original page context and can be triggered by ordinary user actions after navigation.

Practical implication: Clear stored callbacks and listeners on navigation, and never let event handlers outlive the document that registered them.

How javascript: and intent handling become UXSS sinks

A second path appears when apps accept javascript: URIs through deep links, intent extras, or browser fallback flows. If the app forwards those values into loadUrl() without strict scheme validation, the script runs in the current tab or WebView context, bypassing page-level security expectations. The article also shows that cross-app composition can make this worse, because Android intent resolution and installed handlers can turn a seemingly local URI rule into a broader attack surface across browsers and hybrid apps.

Practical implication: Restrict URI handling to http and https, and block javascript: at the manifest, intent, and fallback layers.

Threat narrative

Attacker objective: The attacker wants to execute script on a trusted origin and use that access to hijack sessions, steal tokens, or take over the victim account.

1. Entry begins when the attacker loads a crafted page, a deep link, or a javascript: URI into an Android WebView or browser context that will later accept a native callback.
2. Credential access occurs when the native layer executes evaluateJavascript() or loadUrl("javascript:...") after navigation, letting attacker-controlled code run in the victim origin and reach session material.
3. Escalation happens when the injected script reads authenticated state, manipulates trusted content, or invokes sensitive bridge methods tied to the victim account.
4. Impact is account takeover, session hijacking, or persistent browser compromise depending on which callback or intent path the app exposes.

Breaches seen in the wild

• Gitloker GitHub extortion campaign: Phishing via GitHub notifications tricked developers into authorising malicious OAuth apps; Gitloker then wiped repos and demanded contact.
• 23andMe credential stuffing 2023: Credential stuffing into 18,000 accounts exposed nearly 7 million people through the DNA Relatives feature.

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

Outbound callback trust is the real WebView blind spot. The industry has spent years hardening inbound bridge checks, but this research shows that native reply paths are just as security-sensitive. If a callback can execute after navigation, the trust boundary has already shifted and the original validation no longer protects the current page. Practitioners should treat reply-path validation as a first-class control, not an implementation detail.

TOCTOU on origin is the named failure mode that matters here. The article demonstrates that asynchronous UI work, ambient events, and stored callbacks create a time gap between origin approval and script execution. That gap is enough for an attacker to move the WebView to a victim origin and inherit trust that was never meant for them. In governance terms, the control failed because origin was checked too early and never re-attested at use time.

Mobile identity flows inherit WebView risk whenever authenticated state is reachable from script. Once a callback lands on the wrong origin, the issue is no longer just web injection but identity exposure across sessions, tokens, and account actions. That makes mobile app teams part of the identity governance surface, especially where hybrid apps, embedded browsers, and deep links bridge into authenticated workflows.

Apps that rely on one-off security checks are already behind the threat model. This research shows that a secure inbound bridge can still be undermined by outbound execution, intent resolution, or persistent listeners. The practical implication is that security review must follow the data flow all the way back from callback to originating document, then test whether navigation changes invalidate the trust chain.

Cross-app composition expands the attack surface beyond any single app. The presence of javascript: handlers in one app can change the risk profile of another app on the same device. That means mobile security teams cannot assess WebView exposure in isolation and should think in terms of ecosystem trust, not app-by-app assumptions.

What this signals

TOCTOU on origin is now a mobile governance issue. Teams that treat WebView bridges as a single validation point will miss the moment where trust actually breaks. The practical shift is to govern callback execution as tightly as callback initiation, because navigation can invalidate the original decision before any response lands.

Mobile identity controls need document-bound state, not just user-bound state. If a callback can reach an authenticated page after navigation, the control failure is not just code reuse but identity misbinding inside the app session. Security teams should review embedded web flows, deep links, and session-bearing callbacks as part of the identity attack surface, not only the application layer.

WebView risk now extends beyond one app at a time. Cross-app scheme handling means the device ecosystem can enlarge or shrink exposure in ways single-app testing will miss. That makes scheme restrictions, callback invalidation, and app composition testing core parts of mobile assurance, especially where account access is reachable from embedded web content.

For practitioners

• Audit outbound JavaScript callbacks Trace every evaluateJavascript() and loadUrl("javascript:...") call back to the originating document, then require origin re-validation at the moment of execution.
• Invalidate callback state on navigation Clear stored callbacks, listeners, and pending bridge replies whenever the WebView navigates or the page lifecycle changes, including onPageStarted() and similar navigation hooks.
• Block javascript: in deep link flows Allow only http and https in browser_fallback_url, intent extras, and URL forwarding paths, and reject any javascript: scheme before it reaches loadUrl().
• Test for cross-app composition risk Assess how other installed apps, intent filters, and scheme handlers change your exposure, especially when a WebView or browser accepts external navigation input.
• Review regex-based bridge authentication Replace unanchored origin regexes with host-accurate checks so attacker-controlled paths cannot smuggle a trusted domain match inside a malicious URL.

Key takeaways

• Outbound WebView callbacks can become takeover paths when native code replies after the page has changed.
• The article shows that 13 UXSS findings came from one formalised pattern, with 12 issues found across 20 apps and one account takeover.
• The control failure is origin re-validation at use time, together with callback invalidation on navigation and strict scheme filtering.

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 (TOCTOU): A TOCTOU flaw happens when a system verifies one thing and later acts on a different version of it. In agentic workflows, that means a script, package, or binary can look safe during inspection but be altered before execution, breaking the trust chain.
• Outbound Callback: An outbound callback is the external connection a victim system makes after processing a malicious payload or lookup. In Log4Shell scenarios, it often reveals that the application reached an attacker-controlled host, which can confirm attempted or successful exploitation and provide a strong investigation pivot.
• Schema Validation: A control that checks whether an input matches the declared JSON structure, type, and required fields before it is accepted. In MCP elicitation, schema validation prevents malformed or coerced values from entering the session and corrupting later tool actions.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps security practitioners connect identity controls to the broader attack paths that show up in modern applications and AI systems.