From b1038ec6a707159afccee4d39d1e419e0f84b7a3 Mon Sep 17 00:00:00 2001 From: Dipesh Kumar Date: Fri, 21 Aug 2026 15:22:40 +0530 Subject: [PATCH 1/3] Updating restrictiveXamlReader mode documentation to set correct developer expectations --- dotnet-desktop-guide/wpf/security-wpf.md | 52 +++++++------------ .../xaml-services/security-considerations.md | 16 +----- 2 files changed, 21 insertions(+), 47 deletions(-) diff --git a/dotnet-desktop-guide/wpf/security-wpf.md b/dotnet-desktop-guide/wpf/security-wpf.md index 3684227328..6b1259a89e 100644 --- a/dotnet-desktop-guide/wpf/security-wpf.md +++ b/dotnet-desktop-guide/wpf/security-wpf.md @@ -1,7 +1,7 @@ --- title: "Security" description: Learn about the security model followed when developing Windows Presentation Foundation (WPF) standalone and browser-hosted applications. -ms.date: "03/30/2017" +ms.date: "08/21/2026" ms.service: dotnet-framework ms.update-cycle: 1825-days helpviewer_keywords: @@ -31,19 +31,18 @@ This topic discusses the security model for Windows Presentation Foundation (WPF This topic contains the following sections: -- [Safe Navigation](#SafeTopLevelNavigation) - -- [Web Browsing Software Security Settings](#InternetExplorerSecuritySettings) - -- [WebBrowser Control and Feature Controls](#webbrowser_control_and_feature_controls) - -- [Disabling APTCA Assemblies for Partially Trusted Client Applications](#APTCA) - -- [Loading Untrusted XAML, BAML, and XPS Content](#LoadingUntrustedMarkup) - -- [Sandbox Behavior for Loose XAML Files](#LooseContentSandboxing) - -- [Resources for Developing WPF Applications that Promote Security](#BestPractices) +- [Security (WPF)](#security-wpf) + - [Safe Navigation](#safe-navigation) + - [Application Navigation Security](#application-navigation-security) + - [Browser Navigation Security](#browser-navigation-security) + - [Web Browsing Software Security Settings](#web-browsing-software-security-settings) + - [Security-related WPF Registry Settings](#security-related-wpf-registry-settings) + - [WebBrowser Control and Feature Controls](#webbrowser-control-and-feature-controls) + - [Disabling APTCA Assemblies for Partially Trusted Client Applications](#disabling-aptca-assemblies-for-partially-trusted-client-applications) + - [Sandbox Behavior for Loose XAML Files](#sandbox-behavior-for-loose-xaml-files) + - [Restrictive XAML reader mode](#restrictive-xaml-reader-mode) + - [Resources for Developing WPF Applications that Promote Security](#resources-for-developing-wpf-applications-that-promote-security) + - [See also](#see-also) @@ -259,23 +258,6 @@ If an assembly has to be disabled for partially trusted client applications, you > [!NOTE] > Core .NET Framework assemblies are not affected by disabling them in this way because they are required for managed applications to run. Support for disabling APTCA assemblies is primarily targeted to third-party applications. - - -## Loading Untrusted XAML, BAML, and XPS Content - -WPF exposes several APIs that turn markup into live objects. Because XAML directly represents object instantiation and code execution, loading markup from a source you don't control is equivalent to running untrusted code. The application, not the parser, owns the trust decision about the markup it loads. For the general principles, see [XAML security considerations](../xaml-services/security-considerations.md). - -The following guidance applies to WPF: - -- **Text XAML.** and instantiate arbitrary types and set their properties. Don't load XAML from an untrusted stream, string, file, or network location in your application's process. If you must process untrusted markup, isolate the load in a low-privilege boundary, such as a separate process, and treat the result as untrusted. - -- **Binary XAML (BAML).** BAML is a compiled, tokenized form of XAML that has the same object-construction capabilities as text XAML. BAML is designed to be loaded only from your application's own compiled resources (for example, through ). Treat BAML as trusted only when it originates from a compiled, signed assembly that you produced. Don't load BAML from untrusted streams, files, or documents. - -- **XPS and fixed documents.** Document types such as , , and can reference parts that are loaded as XAML or BAML. Treat an XPS package or fixed document from an untrusted source as untrusted input, and load it in an isolated boundary. - -> [!IMPORTANT] -> A restrictive or allow-list loading mode is a defense-in-depth hardening measure, not a security sandbox. It blocks a set of known-dangerous types, but it still allows many built-in types, some of which can have side effects such as loading external resources or initiating network requests. Don't treat a restrictive parse of untrusted markup as safe. Continue to isolate untrusted markup in a low-privilege boundary. - ## Sandbox Behavior for Loose XAML Files @@ -297,6 +279,13 @@ With this setting, external content will be loaded into a process that is separa > [!NOTE] > Even though navigation to loose XAML files from either a or in a standalone application is implemented based on the WPF browser hosting infrastructure, involving the PresentationHost process, the security level is slightly less than when the content is loaded directly in Internet Explorer on Windows Vista and Windows 7 (which would still be through PresentationHost). This is because a standalone WPF application using a Web browser does not provide the additional Protected Mode security feature of Internet Explorer. +### Restrictive XAML reader mode + +WPF uses the `useRestrictiveXamlReader` mode in some infrastructure loading paths to restrict the instantiation of potentially dangerous types. This mode runs in the caller's process. However, unlike `SandboxExternalContent`, it doesn't create a low-privilege security boundary. + +> [!IMPORTANT] +> A restrictive or allow-list loading mode is a defense-in-depth hardening measure, not a security sandbox. It blocks a set of known-dangerous types, but it still allows many built-in types, some of which can have side effects such as loading external resources or initiating network requests. Don't treat a restrictive parse of untrusted markup as safe. Continue to isolate untrusted markup in a low-privilege boundary. + ## Resources for Developing WPF Applications that Promote Security @@ -319,4 +308,3 @@ The following are some additional resources to help develop WPF applications tha - [Code Access Security](/dotnet/framework/misc/code-access-security) - [ClickOnce Security and Deployment](/visualstudio/deployment/clickonce-security-and-deployment) - [XAML in WPF](xaml/index.md) -- [XAML security considerations](../xaml-services/security-considerations.md) diff --git a/dotnet-desktop-guide/xaml-services/security-considerations.md b/dotnet-desktop-guide/xaml-services/security-considerations.md index 9984c291a2..5282ac63a2 100644 --- a/dotnet-desktop-guide/xaml-services/security-considerations.md +++ b/dotnet-desktop-guide/xaml-services/security-considerations.md @@ -1,7 +1,7 @@ --- title: "XAML Security Considerations" description: Learn about the best practices for security in applications when you use XAML and .NET XAML Services API. -ms.date: 12/16/2025 +ms.date: 08/21/2026 helpviewer_keywords: - "security [XAML Services], .NET XAML services" - "XAML security [XAML Services]" @@ -23,20 +23,6 @@ The nature of XAML capabilities gives the XAML the right to construct objects an In addition to its language-level capabilities, XAML is used for UI definition in many technologies. Loading untrusted XAML might mean loading a malicious spoofing UI. -> [!IMPORTANT] -> There's no supported way to safely load fully untrusted XAML in-process. XAML loading APIs, such as and , instantiate arbitrary types and set their properties, which is equivalent to running arbitrary code. The application, not the parser, owns the trust decision about the markup it loads. If the markup can be influenced by an attacker, isolate the load in a low-privilege boundary, such as a separate process or sandbox, and don't rely on the parser to make it safe. - -### Compiled and binary forms of XAML - -Some technologies compile XAML into a binary or tokenized form that's loaded at run time. A binary form of XAML has the same object-construction capabilities as the equivalent text XAML, so it carries the same trust considerations. Treat a binary XAML source as trusted only when it originates from a compiled, signed assembly or resource that you produced. Don't load a binary XAML source that comes from an untrusted stream, file, or document, and be aware that a container format might embed such content as one of its parts. - -### Restrictive readers are a hardening measure, not a sandbox - -A loading path might offer a restrictive or allow-list reader that blocks a set of known-dangerous types. This kind of reader is a useful defense-in-depth hardening step, but it isn't a security sandbox. A restrictive reader can still allow many built-in types, including types that have side effects such as reaching out to network resources. Don't treat a restrictive parse of untrusted markup as safe. Continue to isolate untrusted markup in a low-privilege boundary. - -> [!NOTE] -> Individual frameworks build on .NET XAML Services and add their own loaders, binary XAML formats, and document containers. For framework-specific guidance about loading untrusted markup in Windows Presentation Foundation (WPF), see [Security (WPF)](../wpf/security-wpf.md). - ## Sharing Context Between Readers and Writers .NET XAML Services architecture for XAML readers and XAML writers often requires sharing a XAML reader to a XAML writer, or a shared XAML schema context. Sharing objects or contexts might be required if you are writing XAML node loop logic, or providing a custom save path. Don't share XAML reader instances, nondefault XAML schema context, or settings for XAML reader/writer classes between trusted and untrusted code. From 6308bf87f3cd7f15c5bd1841152b8c0bdd57c9b1 Mon Sep 17 00:00:00 2001 From: Dipesh Kumar <85861525+dipeshmsft@users.noreply.github.com> Date: Fri, 21 Aug 2026 16:32:01 +0530 Subject: [PATCH 2/3] Rewording restrictive XAML reader mode Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> --- dotnet-desktop-guide/wpf/security-wpf.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dotnet-desktop-guide/wpf/security-wpf.md b/dotnet-desktop-guide/wpf/security-wpf.md index 6b1259a89e..66f921f406 100644 --- a/dotnet-desktop-guide/wpf/security-wpf.md +++ b/dotnet-desktop-guide/wpf/security-wpf.md @@ -281,7 +281,7 @@ With this setting, external content will be loaded into a process that is separa ### Restrictive XAML reader mode -WPF uses the `useRestrictiveXamlReader` mode in some infrastructure loading paths to restrict the instantiation of potentially dangerous types. This mode runs in the caller's process. However, unlike `SandboxExternalContent`, it doesn't create a low-privilege security boundary. +You might encounter the `useRestrictiveXamlReader` mode in some WPF infrastructure loading paths. It restricts the instantiation of potentially dangerous types, but it still runs in your process and doesn't create a low-privilege security boundary like **SandboxExternalContent** does. > [!IMPORTANT] > A restrictive or allow-list loading mode is a defense-in-depth hardening measure, not a security sandbox. It blocks a set of known-dangerous types, but it still allows many built-in types, some of which can have side effects such as loading external resources or initiating network requests. Don't treat a restrictive parse of untrusted markup as safe. Continue to isolate untrusted markup in a low-privilege boundary. From eb22b04f57fa29402acdfaff9c5d25a04da7e338 Mon Sep 17 00:00:00 2001 From: Dipesh Kumar <85861525+dipeshmsft@users.noreply.github.com> Date: Thu, 27 Aug 2026 12:19:21 +0530 Subject: [PATCH 3/3] Update section links in security-wpf.md --- dotnet-desktop-guide/wpf/security-wpf.md | 25 ++++++++++++------------ 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/dotnet-desktop-guide/wpf/security-wpf.md b/dotnet-desktop-guide/wpf/security-wpf.md index 66f921f406..e0c33ae93b 100644 --- a/dotnet-desktop-guide/wpf/security-wpf.md +++ b/dotnet-desktop-guide/wpf/security-wpf.md @@ -31,18 +31,19 @@ This topic discusses the security model for Windows Presentation Foundation (WPF This topic contains the following sections: -- [Security (WPF)](#security-wpf) - - [Safe Navigation](#safe-navigation) - - [Application Navigation Security](#application-navigation-security) - - [Browser Navigation Security](#browser-navigation-security) - - [Web Browsing Software Security Settings](#web-browsing-software-security-settings) - - [Security-related WPF Registry Settings](#security-related-wpf-registry-settings) - - [WebBrowser Control and Feature Controls](#webbrowser-control-and-feature-controls) - - [Disabling APTCA Assemblies for Partially Trusted Client Applications](#disabling-aptca-assemblies-for-partially-trusted-client-applications) - - [Sandbox Behavior for Loose XAML Files](#sandbox-behavior-for-loose-xaml-files) - - [Restrictive XAML reader mode](#restrictive-xaml-reader-mode) - - [Resources for Developing WPF Applications that Promote Security](#resources-for-developing-wpf-applications-that-promote-security) - - [See also](#see-also) +- [Safe Navigation](#SafeTopLevelNavigation) + +- [Web Browsing Software Security Settings](#InternetExplorerSecuritySettings) + +- [WebBrowser Control and Feature Controls](#webbrowser_control_and_feature_controls) + +- [Disabling APTCA Assemblies for Partially Trusted Client Applications](#APTCA) + +- [Loading Untrusted XAML, BAML, and XPS Content](#LoadingUntrustedMarkup) + +- [Sandbox Behavior for Loose XAML Files](#LooseContentSandboxing) + +- [Resources for Developing WPF Applications that Promote Security](#BestPractices)