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.
Editorial analysis by NHI Mgmt Group, based on content published by Novee: “Threat Research Meets AI: How We Found 13 UXSS Vulnerabilities in Android WebView”.
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.
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.
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.
Practitioner guidance
- 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().
Bottom line: Outbound WebView callbacks can become takeover paths when native code replies after the page has changed.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
01/08/2026 9:03 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Android WebView UXSS shows how outbound callbacks create takeover risk