Notifications
Clear all
Topic starter
01/08/2026 8:55 pm
TL;DR: A single TOCTOU-style origin gap in Android WebView let researchers turn one manually found Universal Cross-Site Scripting pattern into 12 additional UXSS findings and one account takeover across 20 apps, according to Novee. Outbound callback paths, not just inbound bridge checks, remain the governance blind spot in mobile app security.
NHIMG editorial — based on content published by Novee: Threat research on 13 UXSS vulnerabilities in Android WebView
By the numbers:
- Then, we formalized the patterns and pointed Novee at 20 Android apps.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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().
- 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.
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.
👉 Read Novee's analysis of Android WebView UXSS and account takeover paths →
Android WebView UXSS and callback trust: where teams still fail?
Explore further
01/08/2026 9:03 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Android WebView UXSS shows how outbound callbacks create takeover risk
