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. That can expose tokens, trusted DOM, or bridge functions to an attacker who has already moved the WebView to a victim origin.
What breaks when a callback runs against the wrong page?
The failure is not just a stale reference, it is a context swap. A callback that was approved for one origin can execute after navigation in a different document, so the code inherits trust it no longer deserves. Once that happens, the page can read or act on data, interfaces, or native bridges that were meant for the original context.
Why navigation turns a safe callback into a security problem
WebView navigation changes the active security boundary while asynchronous work is still in flight. If the callback arrives after a redirect, frame swap, or history change, the approval decision may no longer match the current page. That is why origin checks, frame targeting, and lifecycle checks must be tied to the page that actually receives the callback, not only to the request that scheduled it.
The practical issue is context confusion. A script callback can surface tokens, trusted DOM state, or privileged bridge methods to an attacker who has already steered the WebView to a different origin. Even when the callback content is harmless in the original page, it becomes dangerous once the receiving document is untrusted or attacker-controlled.
What developers usually miss in WebView callback handling
Most mistakes come from treating “callback delivered” as proof that the original trust decision still holds. In reality, asynchronous WebView flows need a current-page validation step, because navigation may have changed the document between scheduling and execution. That includes same-window redirects, SPA-style route changes, iframe replacements, and any host-side callback that assumes the old page context still exists.
Another common mistake is exposing a broad bridge or reusable token to any page that can still receive the callback. If the page can change after the approval point, the callback must be scoped to a specific origin, document, or session state, otherwise the browser container becomes the enforcement gap instead of the application logic.
Risk and Threat Considerations
This pattern is risky because it creates a race between trust establishment and trust use. An attacker only needs to cause navigation before the callback lands, then the WebView may deliver sensitive data or callable privilege into a less trusted security context.
Failure mechanism: The callback is authorized against the initiating page, but executed against a later page after navigation has altered the active origin or document.
Impact: Tokens, page secrets, bridge methods, or sensitive DOM interactions can be exposed to an origin that never earned that access.
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, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V10 — OAuth and OpenID Connect | WebView callbacks often carry auth-related data that must stay bound to the receiving context. |
| Recommendation — Bind callback delivery to the intended redirect or page context and reject any mismatch. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The callback should not expose more page or bridge power than the current context needs. |
| IA-5 — Authenticator Management | Tokens or secrets delivered in a callback need lifecycle and exposure controls. | |
| Recommendation — Limit callback-accessible actions to the minimum privilege needed by the active page. Invalidate or rotate callback-bearing secrets when navigation changes the active context. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | A WebView bridge callback can become an unauthorized function call after navigation shifts context. |
| Recommendation — Recheck function authorization at execution time, not only when the callback is scheduled. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | The active page must be verified continuously instead of trusted once for the whole WebView session. |
| Recommendation — Continuously revalidate the current origin before honoring any callback action. | ||
Practitioner Guidance
What to verify: Bind callback execution to the current origin and document state, and reject the callback if either has changed since the request was issued. If the WebView API does not give you a stable page identifier, add your own per-navigation nonce or session marker and invalidate it on every navigation event.
Common mistake: Do not assume same-tab continuity means same trust context. A page can remain in the same WebView while the security boundary changes completely, so the callback should be treated as untrusted until the active origin is revalidated.
Practitioner takeaway: The safe design is to make callback execution conditional on the page that will receive it, not the page that originally asked for it.