[Feature] Add AllowedDomains URL allowlisting for WebView, HybridWebView, and BlazorWebView by mattleibow · Pull Request #35470 · dotnet/maui

mattleibow · 2026-05-15T20:07:46Z

Note

Are you waiting for the changes in this PR to be merged?
It would be very helpful if you could test the resulting artifacts from this PR and let us know in a comment if this change resolves your issue. Thank you!

Description

Adds an AllowedDomains property (IList<string>?) to WebView, HybridWebView, and BlazorWebView that restricts navigation and sub-resource loading to only the listed domains (and their subdomains).

When AllowedDomains is null or empty, all URLs are allowed (backward-compatible default). When set, only URLs whose host matches one of the listed domains are permitted — blocked navigations are cancelled and blocked sub-resources return 403.

Opt-in, non-breaking API

AllowedDomains is defined by a new optional interface IAllowedDomainsWebView, implemented by WebView, HybridWebView and BlazorWebView. It is intentionally not a base interface of IWebView/IHybridWebView/IBlazorWebView, so existing implementers of those public interfaces are not source/binary broken. Handlers read the allowlist by pattern-matching IAllowedDomainsWebView.

Platform enforcement

Platform	Navigation blocking	Sub-resource blocking
Android	`ShouldOverrideUrlLoading`	`ShouldInterceptRequest` (403)
iOS/MacCatalyst	`WKNavigationDelegate.DecidePolicy`	`WKAppBoundDomains` in Info.plist
Windows	`NavigationStarting` + `FrameNavigationStarting`	`WebResourceRequested` (403, wired only when an allowlist is set)
Tizen	`NavigationPolicyDecided`	navigation-level (Blazor also guards the HTTP interceptor)

Sub-resource blocking now also covers the standard WebView on Windows, and BlazorWebView on Android and Windows (these previously enforced navigation only). BlazorWebView on iOS additionally gets a code-level navigation check in addition to WKAppBoundDomains.

Domain matching

The host is parsed from the URL and compared against each allowlist entry (exact match or .-suffix subdomain match), so the classic bypasses (allowed.com.evil.com, evil.com/?x=allowed.com, userinfo https://allowed.com@evil.com) are rejected.
Comparison uses the ASCII/punycode host (Uri.IdnHost + IdnMapping), so internationalized domain names match whether the allowlist entry or the URL is expressed in Unicode or punycode.

Special schemes (with an active allowlist)

javascript: is blocked (arbitrary script execution / allowlist-bypass vector).
data:, about:, blob: remain allowed (origin-less, page-controlled content; blocking them would break legitimate rendering without adding a security boundary).
App-internal origins (app://0.0.0.0/ for HybridWebView, https://0.0.0.1/ for BlazorWebView, etc.) are always allowed.

iOS/MacCatalyst sub-resource note

Apple's WKWebView cannot intercept http/https sub-resource requests at the code level. For sub-resource blocking, apps must declare up to 10 domains in Info.plist under WKAppBoundDomains and enable LimitsNavigationsToAppBoundDomains = true. The implementation validates consistency between AllowedDomains and the plist at runtime and logs warnings for mismatches.

New types

IAllowedDomainsWebView — optional interface defining the AllowedDomains contract
WebViewDomainAllowlist — shared utility with the IsUrlAllowed() domain-matching logic
WebViewPlistValidator (iOS/MacCatalyst) — validates WKAppBoundDomains plist entries

Tests

WebViewDomainAllowlistTests (Core unit tests) — matcher logic, including the new javascript: and IDN/punycode cases
WebViewAllowedDomainsTests (Controls unit + device tests) — property behavior and navigation blocking
Issue35470 HostApp + UI test — end-to-end navigation allow/block and runtime removal of the allowlist

… and BlazorWebView Adds an AllowedDomains property (IList<string>?) to all three webview controls that restricts navigation to only the listed domains (and their subdomains). When null or empty, all URLs are allowed (backward compatible). Enforcement per platform: - Android: ShouldOverrideUrlLoading + ShouldInterceptRequest (sub-resource blocking) - iOS/MacCatalyst: WKNavigationDelegate DecidePolicy + WKAppBoundDomains/LimitsNavigationsToAppBoundDomains for sub-resource blocking - Windows: NavigationStarting + WebResourceRequested events New files: - IAllowedDomainsWebView interface - WebViewDomainAllowlist shared utility (domain matching logic) - WebViewPlistValidator (iOS/MacCatalyst Info.plist validation) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

github-actions · 2026-05-15T20:08:00Z

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.sh | bash -s -- 35470

Or

Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.ps1) } 35470"

Unit tests (38 tests total): - WebViewDomainAllowlistTests: 29 tests covering IsUrlAllowed() logic (exact match, subdomain, case insensitive, special schemes, app origin, null/empty, port, query, fragment, blocked domains, partial match) - WebViewAllowedDomainsTests: 9 tests for BindableProperty on WebView and HybridWebView (default null, set/reset, PropertyChanged, property exists) Device tests: - WebViewAllowedDomainsTests: 3 tests for platform handler enforcement (allowed navigation succeeds, blocked navigation fails, null allows all) UI tests: - Issue35470 HostApp page: WebView with AllowedDomains set, buttons to test allowed/blocked navigation and runtime removal - Issue35470 NUnit test: 3 Appium tests for end-to-end verification Also fixes WebViewStub to implement IAllowedDomainsWebView.AllowedDomains. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Fixes CS0103 build error for TimeSpan in WebViewAllowedDomainsTests.cs. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

TreatWarningsAsErrors promotes CA1307 to error. Use explicit StringComparison.Ordinal for string.Contains calls. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

mattleibow · 2026-05-20T14:55:27Z

/azp run maui-pr-devicetests

azure-pipelines · 2026-05-20T14:55:40Z

Azure Pipelines successfully started running 1 pipeline(s).

- Windows: Add FrameNavigationStarting handler to block iframe navigations to disallowed domains (WebView + BlazorWebView) - Android: Add ShouldInterceptRequest to MauiWebViewClient to block sub-resource requests (images, scripts, iframes) to disallowed domains - iOS/macCat: Already handled — DecidePolicy fires for all frame types Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

kubaflo · 2026-05-21T11:29:35Z

/review -b feature/regression-check -p android

kubaflo · 2026-05-24T14:27:09Z

/review -b feature/refactor-copilot-yml

kubaflo · 2026-06-01T14:27:40Z

AI code review for net11.0 target

Verdict: Needs changes

Automated, non-approval review comment (no human approval implied). I inspected the diff, the new public surface, and the core allowlist logic independently before reading the PR narrative.

Blocking

All build legs are failing on the PR head (77f5a6e): Build Windows (Debug/Release), Build macOS (Debug/Release) and Pack macOS all fail, while the same legs pass on sibling net11.0 PRs. This is a PR-caused compile/build break (not the shared integration-test flakiness) and must be green before this can be considered. Most likely culprits given the change shape: a PublicAPI.Unshipped.txt mismatch across the 8 touched API files, or the new interfaces (IAllowedDomainsWebView, IWebView/IHybridWebView additions) not being satisfied on every TFM/stub. Please reproduce locally and resolve.

Non-blocking findings

Nullability inconsistency in public API: WebView.AllowedDomains is declared non-nullable (IList<string>, listed with ~ oblivious markers) while HybridWebView/BlazorWebView.AllowedDomains are IList<string>?. Align these for a consistent public contract.
WebViewDomainAllowlist.IsUrlAllowed always allows javascript:/data:/blob:/about: schemes. For a navigation allowlist this is defensible, but javascript: in particular is a common injection vector; worth a comment confirming this is intentional and that sub-resource enforcement (iOS WKAppBoundDomains) is the real boundary.
Subdomain matching (host == domain || host.EndsWith("." + domain)) looks correct and avoids the evilexample.com suffix-trap. Good.

Confidence / CI

Confidence: medium-high on the build-break being PR-caused (all build legs red, isolated to this PR); medium on root cause without log access. Build logs for build 1428352 were not retrievable through tooling.

kubaflo

PR #35470 — Add `AllowedDomains` URL allowlisting for WebView / HybridWebView / BlazorWebView

Verdict: NEEDS_CHANGES (confidence: high) — HEAD 77f5a6e. Unanimous across all 4 models (gpt-5.5, opus-4.8, opus-4.6, gemini). This is a valuable security feature and the core domain matcher is sound — opus-4.8 and I both verified WebViewDomainAllowlist.IsUrlAllowed matches on the parsed Uri.Host with exact + .+domain suffix checks, so the classic bypasses (allowed.com.evil.com, evil.com/?x=allowed.com, userinfo https://allowed.com@evil.com) are correctly handled. The problems are about where the matcher is (and isn't) applied, plus cross-platform parity.

Blocking (inline)

❌ Sub-resource bypass (Android BlazorWebView + Windows). The allowlist is enforced for top-level navigation (ShouldOverrideUrlLoading / NavigationStarting) but not in the resource-request paths (ShouldInterceptRequest on Android, WebResourceRequested/HandleWebResourceRequest on Windows) — so an allowed page can still load scripts/images/XHR from disallowed hosts. This contradicts the PR description's "sub-resource blocking" table. (all 4 models + code-verified)
❌ Tizen is a security no-op. The API is exposed in the Tizen PublicAPI but no Tizen handler enforces it. Setting AllowedDomains on Tizen silently restricts nothing. (gpt-5.5 + gemini + verified)
⚠️ javascript:/data:/blob:/about: unconditionally allowed even with a non-empty allowlist — a real script/content-execution bypass vector. (gemini + verified)
⚠️ iOS/MacCatalyst relies solely on app-configured WKAppBoundDomains (plist validation + warnings) with no code-level IsUrlAllowed nav check for BlazorWebView/HybridWebView, unlike the Controls WebView iOS path and unlike Android/Windows. Inconsistent guarantee. (gemini + opus-4.8)

Also worth addressing (not inline, to keep the review focused)

Public API surface inconsistency across TFMs — WebView.AllowedDomains / the interface entries are declared inconsistently between net / netstandard / net-android / net-windows / net-tizen PublicAPI files (opus-4.8). Reconcile so every TFM matches.
IWebView is now : IView, IAllowedDomainsWebView — adding a required AllowedDomains member to the public IWebView is a binary/source breaking change for any external IWebView implementer (gpt-5.5). If IWebView is considered non-externally-implementable this may be acceptable — confirm.
IDN/punycode: Uri.Host returns Unicode for IDN; ensure allowlist entries and hosts are compared in the same form (gemini suggestion).

CI

Red legs are the usual unrelated infra flakes; the new WebViewAllowedDomainsTests (Core.UnitTests + DeviceTests) are a good start — please extend them to cover the sub-resource and Tizen gaps above.

Great direction and a solid matcher — the fixes are about closing the sub-resource/Tizen/iOS enforcement gaps so the guarantee is consistent across platforms. Happy to re-review.

kubaflo · 2026-06-15T21:03:06Z

 				return false;
 			}

+			if (!Microsoft.Maui.Handlers.WebViewDomainAllowlist.IsUrlAllowed(uri.ToString(), _webViewHandler.VirtualView?.AllowedDomains, AppOriginUri))


Sub-resource allowlist bypass (BlazorWebView Android — and the same pattern on Windows). The AllowedDomains check is applied here in ShouldOverrideUrlLoadingCore (top-level navigation), but the companion ShouldInterceptRequest (lines 85-118 in this file) — which is the path Android WebView uses for images/scripts/CSS/XHR/fetch — does not call WebViewDomainAllowlist.IsUrlAllowed; it only checks app interception + Blazor resources, then return base.ShouldInterceptRequest(...). So a page on an allowed domain can still load sub-resources from a disallowed host (e.g. https://evil.com/x.js). This contradicts the PR description's table, which lists Android sub-resource blocking as enforced via ShouldInterceptRequest. The identical gap exists on Windows: WebView2WebViewManager registers WebResourceRequested for all contexts (AddWebResourceRequestedFilter("*", ...All)) but HandleWebResourceRequest (line 337) serves Blazor content without an IsUrlAllowed check, and the standard Windows WebViewHandler only hooks NavigationStarting/FrameNavigationStarting, never WebResourceRequested. Please enforce the allowlist in the resource-request paths (return an empty/blocked response for disallowed hosts) on both platforms, or correct the PR's sub-resource claims. (All 4 models flagged this; the core IsUrlAllowed matcher itself is sound — this is about applying it at the sub-resource entry points.)

kubaflo · 2026-06-15T21:03:06Z

@@ -1,2 +1,4 @@
 #nullable enable
 static Microsoft.Maui.GridLength.implicit operator Microsoft.Maui.GridLength(string! value) -> Microsoft.Maui.GridLength
+Microsoft.Maui.IAllowedDomainsWebView


AllowedDomains is a security no-op on Tizen. The new IAllowedDomainsWebView / AllowedDomains surface is added to the Tizen PublicAPI here (and in the Controls + BlazorWebView net-tizen baselines), but no Tizen handler (*.Tizen.cs for WebView, HybridWebView, or BlazorWebView) references AllowedDomains, WebViewDomainAllowlist, or IsUrlAllowed — confirmed via git grep at this head. So an app that sets AllowedDomains on Tizen gets a silent false sense of security: navigations and sub-resources are not restricted at all, unlike Android/iOS/Windows which at least block top-level navigation. Either implement enforcement in the Tizen handlers or don't expose the API on Tizen (and document the platform support matrix accordingly). (gpt-5.5 + gemini consensus + verified.)

kubaflo · 2026-06-15T21:03:06Z

+
+			// Always allow special schemes
+			var scheme = uri.Scheme;
+			if (string.Equals(scheme, "data", StringComparison.OrdinalIgnoreCase) ||


data:, about:, javascript:, and blob: are unconditionally allowed even when an allowlist is set. When AllowedDomains is non-empty, the intent is to restrict what the web view can load — but these schemes return true before any host check (lines 33-39). javascript: and data:text/html URLs can execute script / render arbitrary content in the page's origin, and blob:/data: can exfiltrate or load attacker-controlled payloads, so unconditionally allowing them is a real bypass vector for a feature whose purpose is content restriction. Consider at minimum gating javascript: and data: (these are the script/content-execution vectors), or document explicitly that these schemes are intentionally exempt. (gemini flagged; verified.)

kubaflo · 2026-06-15T21:03:06Z

+					config.LimitsNavigationsToAppBoundDomains = true;
+				}
+
+				Microsoft.Maui.Handlers.WebViewPlistValidator.ValidateAllowedDomainsAgainstPlist(allowedDomains, Logger);


iOS/MacCatalyst enforcement relies entirely on the app correctly configuring WKAppBoundDomains, with no code-level fallback. Here the iOS BlazorWebView only validates the plist and logs warnings (WebViewPlistValidator.ValidateAllowedDomainsAgainstPlist) — there's no programmatic IsUrlAllowed navigation check in the WKNavigationDelegate, unlike the Controls WebView iOS path (MauiWebViewNavigationDelegate) which does perform a code-level check. The iOS HybridWebView handler has the same gap (no code-level nav check). The result is an inconsistent security guarantee: if the app doesn't (or can't — WKAppBoundDomains is capped at 10 entries) configure the plist, iOS BlazorWebView/HybridWebView silently enforce nothing, while Android/Windows still block top-level navigation programmatically. Consider adding a code-level decidePolicyForNavigationAction allowlist check on iOS for parity. (gemini + opus-4.8.)

… gaps - Make IAllowedDomainsWebView an optional interface implemented by WebView, HybridWebView and BlazorWebView, instead of a base of IWebView/IHybridWebView/ IBlazorWebView. This avoids a source/binary breaking change for existing IWebView implementers. Handlers read the allowlist via a pattern-matching IsUrlAllowed(string, IView, Uri) overload. - Align WebView.AllowedDomains to IList<string>? and reconcile the AllowedDomains PublicAPI entries so they are consistent across all TFMs. - Block javascript: navigations once an allowlist is active (XSS/bypass vector); data:, about: and blob: remain allowed as page-controlled content. - Match domains using the ASCII/punycode host (Uri.IdnHost + IdnMapping) so IDN allowlist entries and URLs compare correctly. - Close the sub-resource bypass: standard WebView on Windows (WebResourceRequested, enabled only when an allowlist is set), Blazor on Android (ShouldInterceptRequest) and Blazor on Windows (WinUIWebViewManager). - Enforce AllowedDomains on Tizen via NavigationPolicyDecided for the standard WebView and BlazorWebView (previously a no-op). - Add a code-level navigation check for Blazor on iOS in addition to the existing WKAppBoundDomains enforcement. - Make the device-test WebView stub implement IAllowedDomainsWebView and extend the matcher unit tests for the javascript: and IDN behavior. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

github-actions · 2026-07-16T20:08:51Z

Tests Failure Analysis

@mattleibow — test-failure review results are available based on commit ac9f1a3.
To request a fresh review after new comments, commits, or CI runs, comment /review tests.

Test Failure Review: Insufficient data - click to expand

Overall verdict: Insufficient data — 15 checks are failing, but every one of them was uninspectable (the backing AzDO builds 1493722/1493723/1493724 all returned 404 unauthenticated), so zero distinct failures could be extracted and none could be attributed to the PR or dismissed as pre-existing. No net11.0 base builds were available to compare against (0 base builds sampled), so no baseline evidence exists either way. This is a data-collection gap, not a clean run — a human with AzDO access must confirm.

i Uncertain — inaccessible AzDO build/UI-test legs (~14 checks): the maui-pr, maui-pr-uitests, and maui-pr-devicetests builds and legs (e.g. maui-pr-uitests (iOS UITests CoreCLR Controls (vlatest) CollectionView)) returned 404 unauthenticated, so no logs or test names could be read.
i Uncertain — device-test checks unverified (~4 legs): green device-test legs such as maui-pr-devicetests (net11.0 CoreCLR Android Helix Tests Run DeviceTests Android (CoreCLR)) could not be confirmed Failed == 0 (XHarness exits 0 even on failures).
i Uncertain — aborted MacCatalyst legs (~2 legs): maui-pr-uitests (MacCatalyst UITests CoreCLR Controls Shell) and ... Controls CollectionView were CANCELLED, so their status cannot be trusted green.

Coverage: 138 checks · 123 passing · 15 failing · 0 pending · 14 inaccessible · 1 unmapped · 0 unexplained build legs · 0 unaccounted failing checks · 2 aborted failing checks · 0 canceled-build checks · 4 device-test unverified · 0 unattributed · 0 regressed-vs-base. Deterministic ceiling: Insufficient data — 14 failing check(s) could not be inspected (AzDO build/logs inaccessible).

Builds (this PR): maui-pr 1493722, maui-pr-uitests 1493723, maui-pr-devicetests 1493724. Base sampling (net11.0, 0 recent builds per definition): none available.

Recommended action

A human with AzDO dnceng-public access should open the failing maui-pr/maui-pr-uitests/maui-pr-devicetests builds directly to determine whether the failures are PR-caused; automated inspection was blocked by 404s and no baseline was available.

MauiBot

AI Review Summary

@mattleibow — new AI review results are available based on this last commit: ac9f1a3. To request a fresh review after new comments or commits, comment /review rerun.

🗂️ Review Sessions — click to expand

🚦 Gate — Test Before & After Fix

Gate Result: ⚠️ INCONCLUSIVE

Platform: IOS · Base: net11.0 · Merge base: 7f139ed4

🩺 Base branch does not compile — the without-fix build failed. The gate's "does the test fail without the fix" check is unreliable here; this usually means main is broken or a merge-base file went missing. Note: this PR ADDS 3 new file(s), which the gate removes to reconstruct the pre-fix baseline; if the PR's own (never-reverted) test files reference types defined in those new files, the baseline cannot compile — that reflects a new-feature PR the gate cannot isolate a "before" state for, not necessarily a broken main. The with-fix result below is the reliable signal. Investigate before trusting this gate.

/Users/cloudtest/vss/_work/1/s/src/Controls/tests/Core.UnitTests/WebViewAllowedDomainsTests.cs(12,24): error CS1061: 'WebView' does not contain a definition for 'AllowedDomains' and no accessible exte...

Test	Without Fix (expect FAIL)	With Fix (expect PASS)
🧪 WebViewAllowedDomainsTests `WebViewAllowedDomainsTests`	🛠️ BUILD ERROR	✅ PASS — 21s
🧪 WebViewDomainAllowlistTests `WebViewDomainAllowlistTests`	🛠️ BUILD ERROR	✅ PASS — 7s
📱 WebViewAllowedDomainsTests (AllowedDomainsAllowsPermittedNavigation, AllowedDomainsBlocksDisallowedNavigation, NullAllowedDomainsAllowsAllNavigation) `Category=WebView`	🛠️ BUILD ERROR	✅ PASS — 86s
🖥️ Issue35470 `Issue35470`	🛠️ BUILD ERROR	✅ PASS — 247s

🔴 Without fix — 🧪 WebViewAllowedDomainsTests: 🛠️ BUILD ERROR · 39s