WebView ↔ Native Bridges: where trust boundaries get interesting

Android WebViews often sit at an interesting boundary: web content runs inside a native application, while the host application may expose selected native capabilities back to JavaScript.

That can be useful. It can also create a dangerous assumption:

The security of a native bridge depends on the trustworthiness of every document that can execute JavaScript in the bridged WebView.

The boundary

A simplified architecture looks like this:

Web content
    ↓
WebView
    ↓
JavaScript interface
    ↓
Native application code

If the web-content side becomes attacker-controlled, the bridge becomes part of the attack surface. The interesting question is no longer only “can JavaScript execute?” but also “what native capabilities become reachable once it does?”

What I look for

When reviewing this class of application, I usually separate the problem into three questions:

1. Input — Which URLs, deep links, intents, or server-controlled values reach the WebView?
2. Execution — Can those values influence HTML or JavaScript execution?
3. Privilege — Which native objects or methods are available to that JavaScript context?

A bug becomes especially interesting when an unexpected path connects all three.

Practical validation

Static analysis is useful for finding candidates, but runtime validation matters. A good proof-of-concept should establish exactly which boundary was crossed, which native behavior was reached, and what data or action was actually exposed.

That distinction keeps the write-up grounded in demonstrated impact rather than theoretical escalation.