[Breaking Change] Local Network Access (LNA) in WebView2

[Ju-MsGit]

[Breaking Change] Local Network Access (LNA) in WebView2 - Rollout Plan

Summary:

Chromium’s Local Network Access (LNA) restricts web pages from accessing private/local network resources (e.g., localhost, 192.168.x.x, 10.x.x.x) without explicit permission, potentially blocking requests or triggering prompts.
This change can affect WebView2 apps that depend on local network communication.

Details:

• Feature flag name: LocalNetworkAccessChecks, msWebViewAllowLocalNetworkAccessChecks
• Scope: Private/loopback resource accesses
• Purpose of feature: LNA restricts web pages from making requests to private/local network resources without explicit permission, improving security by preventing unauthorized local network access from web content.

Impact:

• Expected Behavior Change: When LNA is enabled, requests from web pages to private/local network resources (localhost, 192.168., 10.) will be blocked unless explicitly permitted. Requests that previously succeeded silently may fail or trigger permission prompts.
• Who is Affected: WebView2 apps that rely on local network communication (e.g., apps communicating with local services, IoT devices, or local host APIs).

Rollout:

• Edge Timeline: LNA specification and implementation are still actively evolving upstream in Chromium.
• WebView2 Timeline:
  143-144 (Current): Off (kill switch) — LNA disabled via ECS kill switch; pre-LNA behavior preserved
  145 (2026-02-12): Off (flag gated) — Force-allow fallback added via msWebViewAllowLocalNetworkAccessChecks (disabled by default)
  Future (TBD): API-controlled — We plan to extend the CoreWebView2PermissionKind enums with additional values to support LNA with the SetPermissionStateAsync. These new values will be honored by the WebView.PermissionRequested event, to give apps explicit control over LNA. Target release will be shared after the upstream Chromium code base for LNA stabilizes.
  Future (TBD): Flag removal — msWebViewAllowLocalNetworkAccessChecks flag will be removed once new APIs are available and adopted.

Testing:

• How to test prior to release: To opt in and identify workflows that may be affected when LNA is eventually enabled, launch with the following feature flags: --enable-features=LocalNetworkAccessChecks,msWebViewAllowLocalNetworkAccessChecks When testing, ensure any cross-origin iframes that need local network access include allow="local-network-access" in the iframe tag.

Known Issues/Changes:

The LNA specification and implementation are still actively evolving, with a significant number of https://issues.chromium.org/issues?q=localnetworkaccess being addressed. Building WebView2 APIs against these shifting semantics would risk frequent breaking changes for partners.

WebView2 Mitigations:

• Version 145-146: Force-allow fallback added via msWebViewAllowLocalNetworkAccessChecks feature flag (disabled by default).
• Future: New WebView2 permission APIs (SetPermissionState, add_PermissionRequested) are planned to give apps explicit control over LNA behavior.

App Actions:

• Code Changes: No action is required at this time, and your existing workflows will continue to work as before. LNA is currently disabled for WebView2 apps.
• Settings/Policy: No action required from app developers, except validation. Apps are encouraged to proactively test with --enable-features=LocalNetworkAccessChecks,msWebViewAllowLocalNetworkAccessChecks to identify potential impacts early.

Timeline and Next Steps:

• Feature Enablement: LNA will remain disabled until the feature stabilizes upstream and new WebView2 permission APIs are available. An updated timeline will be shared once upstream LNA stabilizes.
• Testing Deadline: No immediate deadline. Apps are encouraged to begin proactive testing at their convenience.
• Contact: For questions or concerns, please use the https://github.com/MicrosoftEdge/WebView2Feedback.