MicrosoftEdge / MicrosoftEdge/WebView2Feedback

[Feature] Requesting the possibility to have better granular control on F12 (executing from Console) from WebView2 clients

Open
#4,460 1 comment 0 reactions 1 assignee View on GitHub

@Lakshmisha-KS is already working on this.

Since Feb 12, 2025.

feature request tracked
Dominant language
PowerShell
Stars
526
Forks
67
PR merge metrics
No merged PRs in 30d

Description

Describe the feature/enhancement you need

Recently it comes to my attention that on an unmanaged network connection, while using a simple VPN client application, which uses Webview2, it's possible to trigger F12, using "Inspect" and going to console typing location="https://bing.com" or others like "https://publicsiteIdontwantmyuserstoaccess.com" the end-users gaining access to external resources which shouldn't. The main topic here is how we can control F12 and it's usage, execution of commands from unmanaged scenario from a Webview2 client from a Operating Systems perspective without depending on the application developer ?

The scenario/use case where you would use this feature

It's quite typical to have enterprise users, carrying their devices and connecting for instances to a captive portal. On this situation I'm reporting, the users follow the next steps:

  1. Using a known VPN which uses Webview2 to establish the connection, the user accesses to a captive portal;
  2. It could be any public captive portal we have available this day's, for instance in a coffee shop.
  3. Within this application, I'm now able to right-click and select “Inspect”
  4. This will trigger the DevTools from where I can execute a command within the console like location="https://publicsiteIdontwantmyuserstoaccess.com"
  5. The result of this is that I'll gain access to internet and to resources, before I'm actually establishing the VPN connection to the company;
  6. This offers undesired access to resources and exposes the user machine;
How important is this request to you?

Impactful. My app's user experience would be significantly compromised without it.

Suggested implementation

The suggestion here, is since we can't turn off the F12, it would be important to allow from the OS perspective to develop some methods to control what we can do within WebView2. Ideally, I would like to be able to have a concept of allow\block on what I can execute\or access. Of course, we can consider different layers of abstraction here:

a) Possibility to block the execution of HTTP traffic filter what the user can or cannot access. Like in the Browser, create an Allow\Block list ?

b) Limit what the user can touch on F12 (disabling the console ?)

c) Implement any kind of GPO that would allow better granular control on F12 without breaking dependencies;

Speaking about other possibilities and con's of those:

a) Ask the developers of the VPN client\or affected application to change the code. This is sometimes not possible, because the developer would say it's not their responsibility to block the access, but from who develops the F12 tool. Others say, it's not on their roadmap to add this feature. Others simply do not offer support to the tool anymore;

b) Block the loading of traffic via firewall or other similar policies. This could be an option, but extremely hard to manage, because it will force the creation of numerous rules. Please remember the scenario I'm describing here, I'm not yet connected to a VPN and managing devices it's hard.

What does your app do? Is there a pending deadline for this request?

This application, is a well known VPN client and we have other applications that may suffer about the same.

AB#49718253

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.