Topic starter
01/08/2026 8:55 pm
TL;DR: A single origin gap in Android WebView let one formalised UXSS pattern scale into 13 findings and one account takeover, according to Novee. Outbound callbacks need origin re-checks at execution time, or a page change can turn trusted script delivery into a takeover path.
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: 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.
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.
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.
Glossary terms: Universal Cross-Site Scripting, Time-of-check/time-of-use (TOCTOU), Outbound Callback, Schema Validation
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 7 hours ago by NHI Mgmt Group
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