ASP.NET Core Blazor Hybrid security considerations
This isn't the latest version of this article. To switch to the latest, use the ASP.NET Core version selector at the top of the table of contents.
If the selector isn't visible in a narrow browser window, widen the window or select the vertical ellipsis (⋮) > Table of contents.
This article describes security considerations for Blazor Hybrid apps.
Blazor Hybrid apps that render web content execute .NET code inside a platform Web View. The .NET code interacts with the web content via an interop channel between the .NET code and the Web View.
The web content rendered into the Web View can come from assets provided by the app from either of the following locations:
wwwrootfolder in the app.
- A source external to the app. For example, a network source, such as the Internet.
A trust boundary exists between the .NET code and the code that runs inside the Web View. .NET code is provided by the app and any trusted third-party packages that you've installed. After the app is built, the .NET code Web View content sources can't change.
In contrast to the .NET code sources of content, content sources from the code that runs inside the Web View can come not only from the app but also from external sources. For example, static assets from an external Content Delivery Network (CDN) might be used or rendered by an app's Web View.
Consider the code inside the Web View as untrusted in the same way that code running inside the browser for a web app isn't trusted. The same threats and general security recommendations apply to untrusted resources in Blazor Hybrid apps as for other types of apps.
If possible, avoid loading content from a third-party origin. To mitigate risk, you might be able to serve content directly from the app by downloading the external assets, verifying that they're safe to serve to users, and placing them into the app's
wwwroot folder for packaging with the rest of the app. When the external content is downloaded for inclusion in the app, we recommend scanning it for viruses and malware before placing it into the
wwwroot folder of the app.
If your app must reference content from an external origin, we recommend that you use common web security approaches to provide the app with an opportunity to block the content from loading if the content is compromised:
- Serve content securely with TLS/HTTPS.
- Institute a Content Security Policy (CSP).
- Perform subresource integrity checks.
Even if all of the resources are packed into the app and don't load from any external origin, remain cautious about problems in the resources' code that run inside the Web View, as the resources might have vulnerabilities that could allow cross-site scripting (XSS) attacks.
If the code inside the Web View is compromised, the code gains access to all of the content inside the Web View and might interact with the host via the interop channel. For that reason, any content coming from the Web View (events, JS interop) must be treated as untrusted and validated in the same way as for other sensitive contexts, such as in a compromised Blazor Server app that can lead to malicious attacks on the host system.
Don't store sensitive information, such as credentials, security tokens, or sensitive user data, in the context of the Web View, as it makes the information available to an attacker if the Web View is compromised. There are safer alternatives, such as handling the sensitive information directly within the native portion of the app.
External content rendered in an
When using an
iframe to display external content within a Blazor Hybrid page, we recommend that users leverage sandboxing features to ensure that the content is isolated from the parent page containing the app. In the following Razor component example, the
sandbox attribute is present for the
<iframe> tag to apply sandboxing features to the
<iframe sandbox src="https://contoso.com/foo.html" />
sandbox attribute is not supported in early browser versions. For more information, see Can I use:
Links to external URLs
By default, links to URLs outside of the app are opened in an appropriate external app, not loaded within the Web View. We do not recommend overriding the default behavior.
Keep the Web View current in deployed apps
By default, the BlazorWebView control uses the currently-installed, platform-specific native Web View. Since the native Web View is periodically updated with support for new APIs and fixes for security issues, it may be necessary to ensure that an app is using a Web View version that meets the app's requirements.
Use one of the following approaches to keep the Web View current in deployed apps:
- On all platforms: Check the Web View version and prompt the user to take any necessary steps to update it.
- Only on Windows: Package a fixed-version Web View within the app, using it in place of the system's shared Web View.
The Android Web View is distributed and updated via the Google Play Store. Check the Web View version by reading the
User-Agent string. Read the Web View's
iOS and Mac Catalyst both use
WKWebView, a Safari-based control, which is updated by the operating system. Similar to the Android case, determine the Web View version by reading the Web View's
Windows (.NET MAUI, WPF, Windows Forms)
On Windows, the Chromium-based Microsoft Edge
WebView2 is required to run Blazor web apps.
By default, the newest installed version of
WebView2, known as the Evergreen distribution, is used. If you wish to ship a specific version of
WebView2 with the app, use the Fixed Version distribution.
For more information on checking the currently-installed
WebView2 version and the distribution modes, see the
WebView2 distribution documentation.
Submit and view feedback for