WebView2 'IntegrityFailure' during sub-resource fetching

Question

WebView2 'IntegrityFailure' during sub-resource fetching

Luma Warren (Axon Enterprise) 225

We are observing a significant rendering regression in our custom Teams Tab application following the April 2026 WebView2 runtime update (v148.x). The application’s initial HTML payload loads successfully, but all subsequent CSS and JS sub-resources are failing to execute, resulting in a broken UI.

Diagnostic Analysis:

Fiddler Trace: Captures successful 200 OK responses for all .css and .js files, but the X-Content-Type-Options: nosniff header is triggering a client-side block.

HAR Report Analysis: The .har logs reveal that the WebView2 engine is flagging these requests with a MIME type mismatch error. Specifically, assets served from our secondary CDN are being interpreted as text/plain despite having the correct server-side headers.

Process Telemetry: We are seeing intermittent IntegrityFailure events in the CoreWebView2ProcessFailed handler. It appears the 2026 "Strict" Enhanced Security Mode is enforcing a more rigorous code-integrity check on cross-origin scripts that lack a valid Subresource Integrity (SRI) hash.

Is the Teams 2026 runtime now enforcing Strict Enhanced Security Mode by default for all third-party tabs?

Ashlesha Pawar (Tata Consultancy Services Limited) 235 Reputation points Microsoft External Staff

2026-05-04T11:18:56.32+00:00
Luma Warren (Axon Enterprise) Based on the WebView2 148 release notes, there is no indication that Microsoft Teams or WebView2 has enabled a global “Strict Enhanced Security Mode” by default for third-party tabs.

Enhanced Security Mode (ESM) remains opt-in, and even the newer Origin Configuration API explicitly states that WebView2 applies a uniform policy by default, unless overridden.

The IntegrityFailure reason introduced in Runtime 148 refers to OS-level code integrity failures (e.g., DLL verification issues), not Subresource Integrity (SRI) or missing integrity attributes on scripts.

Given that, the observed behavior is more likely explained by stricter MIME type enforcement in Chromium/WebView2, rather than a new security mode.

In particular:

If responses are interpreted as text/plain while X-Content-Type-Options: nosniff is present, the browser will block execution—even if the server configuration appears correct.

This commonly happens due to CDN edge inconsistencies, redirects, or intermediate proxies altering headers.

Recommended next steps:

Verify actual response headers at the client (not just server config), especially across CDN edges.

Check for redirects or caching layers returning incorrect Content-Type.

Test serving the same assets from the primary origin to isolate cross-origin effects.

Temporarily remove nosniff (for debugging) to confirm MIME enforcement as the cause.

Answer accepted by question author

Gabriel-N 17,450 Microsoft External Staff Moderator

Hello Luma Warren (Axon Enterprise)

I’m really sorry that you’re experiencing this issue. I’ve actually seen a few other tenants report the same problem recently, unfortunately, it looks like this isn’t something I can fully resolve here on the forum, since my capabilities as a moderator are limited.

Given the situation, the best approach would be to escalate this to engineering team for deeper troubleshooting. I recommend creating a support request through the Service Hub so that the engineers can investigate the issue more closely. You can refer to the following article for detailed steps on how to create a ticket: https://learn.microsoft.com/en-us/services-hub/unified/support/open-support-requests?pivots=existing

Thank you for your understanding and patience.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

0 comments

1 additional answer

Your answer

Ashlesha Pawar (Tata Consultancy Services Limited) 235 Reputation points Microsoft External Staff

2026-05-04T11:18:56.32+00:00

Luma Warren (Axon Enterprise) Based on the WebView2 148 release notes, there is no indication that Microsoft Teams or WebView2 has enabled a global “Strict Enhanced Security Mode” by default for third-party tabs.

Enhanced Security Mode (ESM) remains opt-in, and even the newer Origin Configuration API explicitly states that WebView2 applies a uniform policy by default, unless overridden.

The IntegrityFailure reason introduced in Runtime 148 refers to OS-level code integrity failures (e.g., DLL verification issues), not Subresource Integrity (SRI) or missing integrity attributes on scripts.

Given that, the observed behavior is more likely explained by stricter MIME type enforcement in Chromium/WebView2, rather than a new security mode.

In particular:

If responses are interpreted as text/plain while X-Content-Type-Options: nosniff is present, the browser will block execution—even if the server configuration appears correct.

This commonly happens due to CDN edge inconsistencies, redirects, or intermediate proxies altering headers.

Recommended next steps:

Verify actual response headers at the client (not just server config), especially across CDN edges.

Check for redirects or caching layers returning incorrect Content-Type.

Test serving the same assets from the primary origin to isolate cross-origin effects.

Temporarily remove nosniff (for debugging) to confirm MIME enforcement as the cause.

Answer 1

AI answer

The provided information does not state that Teams 2026 (or the underlying WebView2 Runtime 148.x) enforces a “Strict” Enhanced Security Mode by default for all third‑party tabs, nor that such a mode is now on by default.

The only relevant change in the context is the new Origin Configuration API for WebView2, which allows apps to selectively enable or disable features such as Enhanced Security Mode per origin using CoreWebView2Profile.SetOriginFeatures, and to query the effective settings with GetEffectiveFeaturesForOrigin. This API is experimental and opt‑in; the context does not describe any global default change that would automatically apply a strict mode to all third‑party content.

Similarly, the new granular CoreWebView2ProcessFailedReason values (including IntegrityFailure) are exposed behind the msWebView2GranularProcessFailedReason feature flag and become the default behavior starting with WebView2 Runtime release 150, not 148. The context describes these as improved diagnostics for process exits, not as a policy change that enforces SRI or stricter MIME enforcement by default.

Based on the available documentation, there is no confirmation that Teams 2026 has switched all third‑party tabs to a default “Strict” Enhanced Security Mode. The context only confirms:

WebView2 now supports more granular process failure reasons, including IntegrityFailure.
An experimental Origin Configuration API exists to configure features like Enhanced Security Mode per origin.
These capabilities are feature‑flagged/experimental and not documented as globally enforced defaults for all apps or Teams tabs.

References:

AI-generated content may be incorrect. Read our transparency notes for more information.

Share via

WebView2 'IntegrityFailure' during sub-resource fetching

1 additional answer

Your answer