[Problem]: Unable to disable CORS and enable Mixed Content for Private Network Access

[softworkz]

Importance	Blocking. My app's basic functions are not working due to this issue.
Runtime Channel	Stable release (WebView2 Runtime), Prerelease (Edge Canary/Dev/Beta)
Runtime Version	119.0.2151.58 and 120.0.2210.4
SDK Version	1.0.1823.32
Framework	WinUI3/WinAppSDK, UWP
Operating System	Windows 10, Windows 11, Xbox
OS Version	22621.2506

Background

We are trying to port and established application to WebView2. Its core is implemented in HTML/JS, surrounded by platform-specific implementations in native code. The html/js code is installed with the application and it never runs any code or displays any html views from external sources.
In the context of this application, we need to load data from "insecure origins" on the private network via http while the application needs to run in a "secure context".

Why a Secure Context for the Running Code?

Most new APIs are available in a secure context only, and we need to access quite a few of them.

Why only HTTP Connections?

The application interacts with devices (mini-servers) on the local network via REST API and loads images or videos from those devices (which are developed by us as well). These are often fully private and not accessible from outside, which means that they don't have any SSL certs and can only be accessed via http (not https). Since this is targeting end users rather than enterprises, it has to work in a plug'n'play manner and it cannot be expected from users to set up a local PKI/DNS infrastructure.

How do other Platforms Compare?

Android WebView

The app code is running from file: URLs and this context can be declared to be treated secure with a WebView option.

Electron (Windows, Linux, Mac)

The app code is running from file: URLs and Electron provides a way to lift restrictions for this context.

iOS - WebKit WebView

I don't know how we do it there, but there's a way.

UWP/WinJS

There are no mixed content restrictions IIRC

Hosted App (for browser access and PWAs)

This a pretty unfortunate topic. At the moment, we are forced to serve it over http to allow users to access their devices, and we are participating in the Chrome Origin Trial to lift restrictions due to https://wicg.github.io/private-network-access/.
We will implement the "Permission Prompt" mechanism as soon as available (https://github.com/WICG/private-network-access/blob/main/permission_prompt/explainer.md).

Please note that this is acceptable for in-browser access, but it is not a viable option for an installed application using a WebView control.

Problem

Executing a fetch request against a REST API fails and gets blocked with the following error message:

Note

Besides fetch requests, loading images in <img> tags needs to be working as well

What we have tried so far

Serving application files

Using file:// URLs

As there appears to be no way (like the other WebView implementations are providing) to treat this as secure, I have skipped trying this.

Using SetVirtualHostNameToFolderMapping

One way I've tried is using urls like https://appassets/ with this:

CoreWebView2.SetVirtualHostNameToFolderMapping("appassets", "web", CoreWebView2HostResourceAccessKind.Allow);

Using the WebResourceRequested event

The primary way we're using is via the WebResourceRequested event with the same kind of urls: https://appassets/

For the WebResourceResponse I've tried returning https headers like this:

      { "Access-Control-Allow-Headers", "Accept, Accept-Language, Authorization, Cache-Control, Content-Disposition, Content-Encoding, Content-Language, Content-Length, Content-MD5, Content-Range, Content-Type, Date, Host, If-Match, If-Modified-Since, If-None-Match, If-Unmodified-Since, Origin, OriginToken, Pragma, Range, Slug, Transfer-Encoding, Want-Digest, X-MediaBrowser-Token, X-Emby-Token, X-Emby-Client, X-Emby-Client-Version, X-Emby-Device-Id, X-Emby-Device-Name, X-Emby-Authorization" },
      { "Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, PATCH, OPTIONS" },
      { "Access-Control-Allow-Origin", "*" },
      { "Access-Control-Allow-Private-Network", "true" },
      { "Cross-Origin-Resource-Policy", "cross-origin" },
      { "Content-Type", "{0}" },

Command Line Flags

Via Environment Variable

I tried an abundance of different flags in different combinations, all set via WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS environment variable.
Also, I verified that those flags are really being set on the msedgewebview2.exe processes.

--disable-web-security
--allow-insecure-localhost
--unsafely-treat-insecure-origin-as-secure=http:*
--disable-site-isolation-trials
--disable-block-insecure-private-network-requests
--enable-insecure-private-network-requests-allowed
--disable-private-network-access-respect-preflight-results
--disable-features=AutoupgradeMixedContent,PrivateNetworkAccessSendPreflights,PrivateNetworkAccessRespectPreflightResults,BlockInsecurePrivateNetworkRequests
--enable-features=PrivateNetworkAccessNonSecureContextsAllowed,InsecurePrivateNetworkRequestsAllowed
--enable-blink-features=PrivateNetworkAccessNonSecureContextsAllowed,InsecurePrivateNetworkRequestsAllowed

Note: What does work is --unsafely-treat-insecure-origin-as-secure=http://1.2.3.4 but the IP addresses are not known up-front and the setting doesn't support wildcard for IP addresses (as per docs and per trying).

Via CoreWebView2Environment

Somewhere it was stated that disable-web-security wouldn't work via environment variable. As I also have a custom WebView2 control (re-implemented in C# from the WinUI2 C++ code) which allows using CoreWebView2Environment to create a CoreWebView2, I have also tried setting flags via CoreWebView2EnvironmentOptions.AdditionalBrowserArguments

Policies

I tried setting the following policies

AutomaticHttpsDefault 0
InsecurePrivateNetworkRequestsAllowed 1

Distribution Modes

I tried with the evergreen runtime 119.0.2151.58 and the canary version 120.0.2210.4

I tried with fixed version distribution: 119.0.2151.58

[softworkz]

Any update on this?
Thanks

[monica-ch]

@softworkz Can you please check if corewebview2customschemeregistration works for your case to serve the content.

Also, you mentioned trying SetVirtualHostNameToFolderMapping and handling the WRR event by providing the response. Is there an issue using that approach?

[softworkz]

@softworkz Can you please check if corewebview2customschemeregistration works for your case to serve the content.

For working with CustomSchemeRegistrations, you need to set those at the CoreWebView2EnvironmentOptions.CustomSchemeRegistrations property when creating an environment.

The link above points to the .NET API, in the WinRT API that property is missing.
Even when it existed, it wouldn't be possible to use it, because neither the UWP/WinUI2 nor the WinUI3 Webview2 element does allow you to create the environment yourself, so there's not way to use custom scheme registrations with UWP and WinUI3.

Please see my related proposal on this subject.

Nonetheless I was still able to try this, because I have done a custom WebView2 element for WinUI3 (a C# port of the official XAML control with extra capabilities), and so I can say:

No, that doesn't work. For a custom scheme, you can set TreatAsSecure to true or false and the result is the same as whether using http or https:

• true/https: You can use web APIs (e.g. WebHID, SpeechRecognition, etc.) but you cannot connect to http endpoints on the local network
• false/http: You can connect to http endpoint on the local network, but you cannot use web APIs which require a secure context

Also, you mentioned trying SetVirtualHostNameToFolderMapping and handling the WRR event by providing the response. Is there an issue using that approach?

I don't have an issue using that approach per se, but it doesn't help with the situation either. With that approach, you have the choice to use http or http, with the same outcome as above (see "true/https" and "false/http").

[JaroslavHerber]

Any news on this?

Also run into this. Loaded a <video> Tag with a src-URL that had a redirect to a http://[IP-address]:[Port]/some-media.mkv source, which is blocked.

While we can set all kinds of flags to disable security mechanics, Chromium simply doesn't like IP-based HTTP-Requests. Any ideas?