[Upcoming Breaking Change] Enabling Isolate Sandboxed Iframes by Default

[victorhuangwq]

Enabling a new Chromium flag IsolateSandboxedIframes by default, which causes AddWebResourceRequestedFilter API to no longer be able to intercept requests from sandboxed iframes if no request source kinds are defined.

Who would be affected?
Any apps using AddWebResoucreRequestedFilter API (.NET / WinRT / Win32) to intercept requests made from sandboxed iframes without the allow-same-origin attribute.
Apps are not affected if they are already defining RequestSourceKinds using the newer APIs ( .NET / WinRT / Win32)

What’s the change, and why?
IsolateSandboxedIframes feature will be enabled by default, latest by major version 132’s runtime, which means that documents with sandboxed iframes without the allow-same-origin attribute that previously remained in the same process as their parent or opener, even with an opaque origin, will now be moved into a separate process.

This Chromium change enhances security and process isolation by ensuring that sandboxed iframes are treated as separate processes. This helps to mitigate potential security risks associated with same-process execution of sandboxed content.

However, WebView2's AddWebResourceRequestedFilter API by default doesn't intercept requests from out-of-process iframes (OOPIFs), so it will no longer intercept these.

What should you do?
If your app uses the AddWebResoucreRequestedFilter API (.NET / WinRT / Win32) API to intercept resource requests from sandboxed iframes, you should include define RequestSourceKinds using the newer APIs( .NET / WinRT / Win32) to intercept out-of-process iframes.

This parameter allows you to specify the source of the resource requests, ensuring that your app can also intercept requests made by OOPIFs.

Sample code:

C#

webView.CoreWebView2.AddWebResourceRequestedFilter(
     "*", 
     CoreWebView2WebResourceContext.All,
     CoreWebView2WebResourceRequestSourceKinds.Document
 );

C++

webView2_22->AddWebResourceRequestedFilterWithRequestSourceKinds(L"*", 
COREWEBVIEW2_WEB_RESOURCE_CONTEXT_ALL, 
COREWEBVIEW2_WEB_RESOURCE_REQUEST_SOURCE_KINDS_DOCUMENT);

By adding RequestSourceKinds ( .NET / WinRT / Win32), you ensure that your app can intercept requests made by out-of-process iframes. This is crucial because, with IsolateSandboxedIframes enabled, sandboxed iframes will run in separate processes, and without this parameter, your app would not be able to intercept their requests.

Please transition to the new API to take full advantage of the API to intercept all the necessary requests and to avoid any regression due to any changes in the chromium process models for iframes. Doing so will ensure compatibility with WebView2 runtime 132 onwards to take full advantage of the API that intercepts all the requests.

How can I verify if I have addressed the issue?
You can verify by running your WebView using AdditionalBrowserArguments ( .NET / WinRT / Win32) API to enable the feature with the flag: IsolateSandboxedIframes. You have addressed the issue, if you are able to intercept resources from sandboxed iframes

What happens if I am not able to make the API change by 132?
If you see regressions when Sandboxed iFrames is enabled in 132, and you were not able to make the change to your app to adopt the new API, you can use this temporary WV2 flag msEdgeWebViewApplyWebResourceRequestedFilterForOOPIFs to enable. When enabled, the older WebResourceRequested will fire for OOPIFs as well.