Security & App Isolation

Security features answer specific threats, so name the threats first. A lightweight STRIDE pass over Bookshelf Desktop (the method is the one the book discussed later on this page recommends) gives a short list:

The point of the exercise is the right-hand column: every control below exists because a row above needs it. Treating the list as a living document (re-run it whenever a feature adds a file format, a network call or a plug-in point) is more valuable than any single setting.

A Windows desktop process lives in exactly one of three tiers, and the tier decides what the rest of the page can do for you.

The Windows App SDK documentation states it plainly: WinUI 3 desktop apps packaged as MSIX typically run at medium integrity level (full trust) in a less restrictive sandbox, not in an AppContainer, unless you explicitly configure them as AppContainer apps. Do not describe "an MSIX app" as sandboxed without saying which tier you mean.

Even in full trust, package identity changes how the OS treats the install, and some of it is a security benefit.

The last row is the one people miss. File and registry virtualization in a full-trust package exists so that old apps keep working and uninstall leaves nothing behind. It does not stop the app (or code injected into it) from touching other files the user can touch. For that you need the AppContainer tier.

A capability is a manifest declaration that grants an AppContainer app access to a protected resource. They are declared in Package.appxmanifest under Capabilities and fall into general-use, device, restricted and custom categories. The relevant facts for a desktop developer are:

User Account Control lets users work as standard users while administrators run most programs with a filtered token. A desktop app declares what it needs in an application manifest (the Win32 side-by-side manifest embedded in the .exe, distinct from Package.appxmanifest) through the requestedExecutionLevel element under trustInfo.

The optional uiAccess attribute lets an application bypass user-interface protection levels and drive input to higher-privilege windows. It defaults to false and Microsoft says to set it to true only for user interface accessibility applications, subject to security policy that can require the app to be installed in a secure location. Bookshelf Desktop is not an assistive technology and leaves it false.

Source: Application manifests.

Add the file to the project as app.manifest and point the SDK-style project at it:

Source: WPF documentation for the project shape; the ApplicationManifest property is the standard MSBuild way to embed a manifest.

Bookshelf Desktop can sync a library with a remote service, so it holds a long-lived token. The wrong places are the usual ones: a settings file, an embedded constant, an environment variable written to disk, a log line. The Windows options are summarised below.

DPAPI is documented as a way to encrypt data with information from the current user account or the computer so you avoid the difficult problem of generating and storing a key yourself. ProtectedData is available on .NET and .NET Framework (the in-memory counterpart, ProtectedMemory, is documented for .NET Framework 2.0 to 4.8.1 only, see ProtectedMemory class), and on .NET it ships in the System.Security.Cryptography.ProtectedData NuGet package. DataProtectionScope.CurrentUser limits decryption to the same user account; DataProtectionScope.LocalMachine lets any account on the computer decrypt, which is almost never what a per-user token wants.

System.Windows.Markup.XamlReader loads XAML at run time and returns the root of the object tree. XAML can instantiate arbitrary types and set their properties, so loading markup from an untrusted file, e-mail attachment or server response is equivalent to running code chosen by whoever wrote that markup. The language-level mechanics are in XAML Language Fundamentals; the security rules follow.

Source: XamlReader.Load method. The class-level remarks of the restrictive overloads are the basis of the warning above. The two catch clauses are a Bookshelf choice; the page lists ArgumentNullException as the only documented exception, so test which exception a malformed or blocked document throws with the documents you expect.

For WinUI 3 and UWP, the equivalent loader is Microsoft.UI.Xaml.Markup.XamlReader; the restrictive overloads are documented for WPF only, so the guidance to avoid loading untrusted markup applies even more strongly there.

A desktop app ships its dependencies to every customer, so a vulnerable package is a vulnerability in each installed copy. NuGet checks restored packages against vulnerability data on nuget.org, which is sourced from the GitHub Advisory Database.

Audit raises warnings NU1901 (low), NU1902 (moderate), NU1903 (high) and NU1904 (critical); NU1900 means the vulnerability data could not be retrieved and NU1905 means an audit source provides no vulnerability database. A sensible policy is to keep audit warnings non-blocking for everyday builds and treat them as errors in one dedicated pipeline run, so that a newly published advisory does not break an unrelated bug fix at an awkward moment.

Source: Auditing package dependencies for security vulnerabilities. The dotnet package update --vulnerable command (NuGet 7.0, .NET 10 SDK) updates vulnerable packages to the first version without known vulnerabilities. The page notes that --include-transitive is not the default for dotnet list package --vulnerable, so pass it. For a vulnerable transitive package, first try updating the direct package closest to it, then pin the fixed version, and suppress an advisory with a NuGetAuditSuppress item only as a last resort after analysing it.

Two related habits belong here: keep the target framework on a supported release (.NET 8 and .NET 9 end support on 10 November 2026, .NET 10 LTS on 14 November 2028), and prefer a single trusted feed that upstreams from nuget.org, using auditSources in NuGet.Config so the vulnerability lookup does not force nuget.org as a package source.

Signing answers "who published this, and was it changed?" Two Windows features read that answer.

Microsoft Defender SmartScreen checks the reputation of downloaded files from two signals: publisher reputation (is the file signed by a known, trusted publisher?) and file-hash reputation (has this exact file been downloaded without signs of malicious behaviour?). A new binary can still show a warning until reputation accumulates.

Points that change how you plan a release:

Whatever the certificate source, the pipeline must read the key material from secrets. A command-line example with signtool that never contains a credential:

Source: SmartScreen reputation for Windows app developers for the reputation rules. The signtool switches shown are the standard ones; the signing and packaging pages of this section cover the full workflow, including the MSIX requirement that the manifest Publisher match the certificate subject.

An update mechanism is a remote-code-execution path by design, so it deserves its own review. The controls are the same for every channel; what differs is who enforces them.

The channel rows summarise how each distribution page of this section behaves; follow them for the specifics. Rules that hold everywhere:

The first two rows come from the MSIX and capability documentation. The ApplicationData note is stated by the app-data article: those APIs are designed for packaged apps, and unpackaged apps must use other storage. Trimming and Native AOT are covered by the publishing-options page of this section; they are build-size and start-up features, not security controls.

Tidjani Belmansour’s Building CLI Applications with C# and .NET (Packt, 2025) devotes its thirteenth chapter to security. Its central claim is that security is not only the application’s code or its authentication but the whole lifecycle, and it walks through the stages. The book targets console applications on .NET 8, so some items need translating. The table keeps the book’s structure and states what each stage means for a Windows desktop app. This page cites the book for its checklist only; the Windows-specific controls come from the Microsoft documentation listed in the references.

The same chapter also covers three tools and ideas that map directly:

One translation deserves emphasis. A CLI user types a token on a command line, so the book recommends not passing it as a parameter. A desktop app has no command line for end users, but it has the same underlying problem: wherever the token comes to rest on disk, an attacker running as the user can read it, which is why the operating-system stores above are preferred to files.

Choose the trust tier on purpose (unpackaged, packaged full trust, or AppContainer), declare the smallest execution level and capability set that works, keep secrets in an operating-system store behind an interface, treat run-time XAML as code, audit dependencies on every restore, sign every release and protect the pipeline that signs it, and re-run a short threat model whenever a feature adds an input, a file format or a network call.