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.
Why javascript: and WebView callback handling becomes a security boundary
The issue is not the URI scheme by itself, it is whether an untrusted flow can smuggle executable browser context into an Android app and make the app treat it as trusted. Once a WebView, intent handler, or bridge callback accepts attacker-controlled navigation state, the app can be pushed into executing logic under the wrong origin or with the wrong privilege assumptions.
That is why the safest response is to treat scheme handling, origin validation, and bridge invocation as one control plane, not three separate checks. If any of those pieces is permissive, the app may still appear to “work” while quietly accepting a path that should have been rejected.
Android teams usually need to review this in the same way they would review other app-level trust boundaries: what content is allowed to enter, what state is retained across navigation, and what code runs after a redirect, callback, or fallback URL changes the execution context.
How to constrain the accepted execution path
The practical baseline is to allow only http and https where external content is expected, and to reject javascript: as an input scheme for untrusted flows. If a flow truly needs a callback or deep link, the app should normalize the input first and then re-validate the active origin at the moment the action is about to execute, not only when the link is first received.
This matters because the original source of a URL is not the same thing as the active context when a WebView callback fires. Redirects, in-app navigation, fallback URLs, and cross-app intent handling can all change the trust boundary after initial parsing, so the execution decision must be made against the current state.
Bridge state also needs lifecycle hygiene. When navigation changes, pending bridge data should be cleared so that a method call from one origin cannot be replayed or reused after the page has moved somewhere else. If the app exposes authenticated bridge methods, they should be reachable only after the app confirms that the caller is still in the intended trust context.
What to retest when a bridge or callback is exposed
These cases should be retested with the same discipline as an injection path, because the unsafe behavior often appears only when one path is chained into another. Deep links, fallback URLs, and cross-app intent handlers are especially important because they frequently route around the app’s “normal” navigation path and can expose code that was only validated under ideal conditions.
Cross-app testing should confirm that a hostile app cannot hand the WebView a crafted callback, switch it into a permissive origin, or preserve a stale bridge state long enough to invoke a sensitive method. If authenticated bridge methods exist, verify that authentication alone is not being used as a substitute for origin checks or navigation-state checks.
For teams using WebView as a lightweight integration layer, the key question is whether a trusted UI action can still be reached after the page has changed hands. If the answer is yes, the boundary is too loose and the callback design needs to be tightened before release.
Risk and Threat Considerations
Untrusted javascript: handling and weak WebView callback control can turn a navigation feature into an execution primitive. The main risk is that an attacker-controlled flow gains the ability to run logic in a context the app still treats as trusted, which can lead to data exposure, unauthorized actions, or bridge misuse.
Failure mechanism: The app accepts an input URL or callback without re-checking scheme, origin, and navigation state at execution time, so a redirect or stale bridge reference lets untrusted content inherit privileged app behavior.
Impact: Sensitive bridge methods, account-linked actions, or in-app data paths may become reachable from an untrusted source, especially when deep links, fallback URLs, or intent-based handoffs are allowed to alter the execution path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V10 — OAuth and OIDC | Covers web callback and redirect trust decisions that depend on current caller context. |
| V8 — Authorization | Applies when bridge methods or callbacks gate privileged app actions by caller context. | |
| V12 — Secure Communication | Relevant because WebView flows should restrict accepted schemes and trusted navigation paths. | |
| Recommendation — Validate redirect and callback handling against the active trust context before invoking sensitive flows. Enforce authorization checks on each bridge action rather than trusting prior navigation state. Restrict accepted schemes and reject untrusted navigation paths before content is loaded. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Bridge callbacks can expose privileged functions if untrusted flows reach them. |
| API2 — Broken Authentication | Authenticated bridge methods still need caller and context checks to prevent misuse. | |
| Recommendation — Verify that every callable bridge function is inaccessible from untrusted flows. Reauthenticate or revalidate the caller context before allowing sensitive bridge actions. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Addresses insecure app input handling and unsafe client-side execution paths. |
| Recommendation — Harden mobile app trust boundaries and test untrusted input paths before release. | ||
Practitioner Guidance
What to verify: Confirm that scheme filtering, origin validation, and bridge invocation are enforced at the point of use, not only during initial URL parsing. The control is only trustworthy if a navigation change invalidates any pending bridge state.
Common mistake: Teams often validate the first redirect and then assume later callbacks are safe. That is the wrong assumption for WebView flows, because the attacker usually wins by changing context after the initial check has already passed.
Decision rule: If a callback can reach authenticated or state-changing functionality, treat it as a high-value boundary and require a fresh trust decision for every navigation transition.
Practitioner takeaway: The real security problem is not whether the app can open a URL, it is whether the app can still tell who controls the page when the callback finally fires.
Related resources from NHI Mgmt Group
- What do teams get wrong when implementing redirect URIs and OAuth callbacks for single sign-on flows?
- How should mobile app teams handle OAuth redirect URIs that carry authorization codes on Android?
- How should security teams respond when a third-party OAuth app is compromised?
- How should teams govern Salesforce client credentials flows for server-to-server callbacks?