Supported way to bind an intercepted request to the current top-level document instance?

[Zandual]

We are designing a security-sensitive WebView2 host on Windows and need clarification on the guarantees WebView2 provides for request attribution and document lifetime.

Environment

• WebView2 Runtime target: 155.0.4283.62
• WebView2 SDK: 1.0.3856.49
• Windows x64
• Native host retains the specific WebView2/Core instance.
• Privileged browser traffic can be intercepted and held before backend processing.
• We are considering WebResourceRequested and/or CDP Fetch.requestPaused plus Network.requestWillBeSent.

Security property we need

Before authorizing a privileged request, the native host needs to establish that:

This particular paused/intercepted request originated from the currently approved top-level document instance in this specific WebView2, and that the approved document has not been replaced, navigated, restored, or otherwise invalidated before authorization is granted.

We can fail closed for ambiguous cases and restrict privileged traffic to a very narrow path, such as a single top-level-page XHR request.

1. Request-to-document identity

Is there a supported WebView2 or CDP mechanism that allows the host to bind a particular intercepted request to the current top-level document instance/generation, rather than merely to a frame, URL, loader, or WebView?

For example, can a documented combination of:

• Fetch.requestPaused
• Network.requestWillBeSent
• request/network IDs
• frame ID
• loader ID
• execution-context identity
• navigation/document lifecycle events

establish this relationship reliably?

If so, which API/event combination is intended for this purpose, and which identifier should be treated as the document-lifetime identity?

2. Ordering guarantee

Is there a documented ordering guarantee that lets the host know that no document replacement/navigation/lifecycle transition has occurred but is still waiting to be reported when an intercepted request is being authorized?

In other words, is it safe to reason:

All relevant lifecycle callbacks observed so far still describe document generation E, therefore this intercepted request belongs to E.

Or can browser/renderer state change before the host receives the corresponding lifecycle notification?

We specifically care about:

• normal navigation and reload
• same-document navigation
• document.open()
• renderer replacement/crash recovery
• BFCache restore
• frame/target replacement

3. Restrictive design

If WebView2 does not provide a direct document-instance/request guarantee, is there a supported restrictive construction that can make this property enforceable?

For example:

• fresh dedicated WebView2/Core for the privileged page
• only the top-level document receives privileged authority
• subframes/workers/service workers cannot perform privileged operations
• redirects/retries receive no inherited authorization
• only one narrow XHR path is eligible
• all navigation/document replacement revokes authority
• ambiguous requests fail closed

Would such a design still require a platform-level document/request identity guarantee, or is there a supported way to enforce these restrictions from the native host?

4. Version-specific mapping

We also need to qualify behavior specifically for WebView2 Runtime:

155.0.4283.62

Is there an authoritative mapping for this WebView2 Runtime build to:

• its Chromium revision/build, and
• the exact applicable DevTools Protocol schema/revision?

We do not want to assume that current tip-of-tree CDP documentation exactly describes this runtime.

Why we are asking

This is not about identifying the renderer process or transport socket. We specifically need a trustworthy current-document → intercepted-request relationship before granting native authorization.

If WebView2 does not provide this guarantee, that answer is also useful because we can redesign the security boundary instead of relying on an unsupported assumption.

Could the WebView2 team clarify what is officially supported here and, if possible, point us to the relevant documentation or source contract?