Blazor-Sicherheit: 12 Punkte, die Sie vor dem Go-live prüfen sollten

Die meisten Sicherheitsvorfälle in Geschäftsanwendungen sind nicht raffiniert. Ein Schlüssel im Repository, ein Token, das nie abläuft, ein Bildschirm, der einen Button versteckt, aber nicht die Aktion dahinter. Blazor bringt vernünftige Voreinstellungen mit, lässt aber Oberflächen- und Servercode fast gleich aussehen, und genau dort verstecken sich die einfachen Fehler.

Hier sind zwölf Prüfungen, die sich vor dem Go-live einer Blazor-Anwendung oder vor dem nächsten Audit lohnen. Einige gelten überall, andere nur für einen bestimmten Render-Modus.

Überall

1. Berechtigungen gehören in den Service, nicht nur in die Oberfläche

AuthorizeView entscheidet, was der Nutzer sieht. Es entscheidet nicht, was der Nutzer tun darf.

<AuthorizeView Roles="Finance">
    <button @onclick="() => Payments.ApproveAsync(payment.Id, user)">Approve payment</button>
</AuthorizeView>

Den Button zu verstecken ist gute Benutzerführung, aber der Schutz muss in der Methode sitzen, die die Arbeit macht, damit er gilt, egal welcher Bildschirm, welche API oder welcher künftige Entwickler sie aufruft:

public sealed class PaymentService(IAuthorizationService authorization, PaymentRepository payments)
{
    public async Task ApproveAsync(int paymentId, ClaimsPrincipal user)
    {
        var result = await authorization.AuthorizeAsync(user, "ApprovePayments");
        if (!result.Succeeded)
            throw new UnauthorizedAccessException();

        await payments.ApproveAsync(paymentId);
    }
}

Seiten werden mit @attribute [Authorize] geschützt, sensible Aktionen mit einer Policy im Service. Beides, nicht eins von beiden. Dieselbe Regel gilt für einen KI-Assistenten in der Anwendung.

2. Keine Secrets im Repository

Connection Strings, API-Schlüssel und Zertifikate gehören in Azure Key Vault oder in die Einstellungen der Hosting-Umgebung, lokal in den Secret Manager, nicht in appsettings.json. Wurde ein Schlüssel je committet, reicht Löschen nicht, denn er bleibt in der Git-Historie. Er muss ersetzt werden.

3. Tokens und Schlüssel, die ablaufen

API-Schlüssel ohne Ablaufdatum und Sitzungen, die monatelang gelten, sind eine offene Tür, an die sich niemand erinnert. Jeder Schlüssel braucht einen Verantwortlichen, ein Ablaufdatum und einen Weg, ihn zu widerrufen.

4. Bekannte Schwachstellen in NuGet-Paketen

Seit dem .NET 8 SDK warnt NuGet beim Wiederherstellen vor Paketen mit bekannten Schwachstellen. Diese Warnungen dürfen nicht unterdrückt und vergessen werden. Für ältere Anwendungen zeigt unser kostenloses Tool zur .NET-Framework-Migration, welche Ihrer Pakete bekannte Schwachstellen haben.

5. Rohes HTML nur aus vertrauenswürdigen Quellen

Blazor kodiert alles, was es darstellt, sodass Text, den ein Nutzer eingibt, nicht zum Skript werden kann. Die Ausnahme ist MarkupString, das HTML unverändert darstellt. Kommt dieses HTML von Nutzern, aus E-Mails oder externen Systemen, muss es vorher bereinigt werden.

6. Detaillierte Fehler nur in der Entwicklung

DetailedErrors schickt den vollständigen Fehler mit Details an den Browser. Auf dem Rechner eines Entwicklers ist das nützlich, in Produktion ein Geschenk an Angreifer. In Produktion bekommt der Nutzer eine kurze Meldung, und die Details gehen ins Log, zum Beispiel nach Application Insights.

7. Limits für Anmeldung und teure Operationen

Anmeldung, Passwort-Reset und Exporte, die die Datenbank stark belasten, brauchen ein Limit, wie viele Anfragen ein Nutzer oder eine Adresse senden darf. ASP.NET Core bringt das mit AddRateLimiter mit.

8. Sicherheits-Header und CSP

Eine Content Security Policy sagt dem Browser, welche Skripte er ausführen darf. Blazor hat eigene Anforderungen: Eine WebAssembly-Anwendung braucht wasm-unsafe-eval in der Policy. Setzen Sie die Policy bewusst und testen Sie sie, statt sie wegzulassen, weil „etwas nicht mehr funktioniert hat“.

Statische Formulare

9. Schutz vor gefälschten Anfragen (Antiforgery)

In einer Blazor Web App sind serverseitig gerenderte Formulare gegen Cross-Site Request Forgery geschützt, wenn die Anwendung app.UseAntiforgery() aufruft. EditForm fügt das Token selbst hinzu, ein einfaches HTML-<form> braucht die Komponente <AntiforgeryToken />.

Interactive Server

10. Verbindungslimits nicht blind erhöhen

Bei Interactive Server hält jeder Nutzer eine Verbindung und Speicher auf dem Server. Blazor hat Limits für Nachrichtengröße und dafür, wie viel pro Nutzer gepuffert wird, und sie zu erhöhen, „weil ein Upload nicht ging“, öffnet den Weg, den Server zu erschöpfen. Große Dateien gehören in einen eigenen Upload, nicht in eine riesige Nachricht. Wie sich Speicher pro Nutzer summiert, beschreibt der Artikel über langsame Blazor-Anwendungen.

WebAssembly

11. Nichts Geheimes im Client

Alles, was eine WebAssembly-Anwendung enthält, wird in den Browser geladen: Code, Konfiguration und Bibliotheken. Microsoft sagt klar, dass Connection Strings, Schlüssel, Passwörter und privater Code dort nie liegen dürfen. Berechtigungsprüfungen im Browser lassen sich umgehen, also muss jede API die Berechtigungen auf dem Server erneut prüfen.

12. Tokens bleiben auf dem Server

Zugriffstokens im lokalen Speicher des Browsers sind ein leichtes Ziel. Microsofts empfohlener Ansatz für Blazor Web Apps ist das Backend-for-Frontend-Muster: Der Server hält die Tokens und spricht mit den APIs, der Browser bekommt nur ein sicheres Cookie.

Die Checkliste in einer Tabelle

#	Prüfung	Gilt für
1	Berechtigungen in Services, nicht nur in der Oberfläche	Überall
2	Keine Secrets im Repository	Überall
3	Schlüssel und Tokens, die ablaufen	Überall
4	Keine bekannten Schwachstellen in NuGet-Paketen	Überall
5	MarkupString nur für vertrauenswürdiges HTML	Überall
6	Detaillierte Fehler in Produktion aus	Überall
7	Limits für Anmeldung und teure Operationen	Überall
8	Bewusste CSP und Sicherheits-Header	Überall
9	Antiforgery für Formulare	Statische Formulare
10	Verbindungslimits bleiben bestehen	Interactive Server
11	Nichts Geheimes im Client	WebAssembly
12	Tokens auf dem Server (BFF)	WebAssembly

Welcher Render-Modus für welchen Bildschirm passt und was das für die Sicherheit bedeutet, steht im Artikel Blazor Server vs WebAssembly vs Auto.

Wie wir arbeiten

Wir prüfen Blazor- und .NET-Anwendungen genau anhand dieser Liste und beheben, was wir finden, von Berechtigungen, die nur in der Oberfläche existierten, bis zu Schlüsseln, die im Repository gelandet sind. Sie bekommen eine priorisierte Liste der Risiken, von denen, die sich diese Woche zu beheben lohnen, bis zu denen, die warten können. Mehr über unsere Arbeit mit Blazor, und der erste Schritt ist ein kostenloses 30-minütiges Gespräch.

Quellen

• ASP.NET Core Blazor authentication and authorization, Microsoft Learn
• Secure ASP.NET Core Blazor WebAssembly, Microsoft Learn
• Threat mitigation for interactive server-side rendering, Microsoft Learn
• Secure a Blazor Web App with OpenID Connect, Microsoft Learn
• Content Security Policy for Blazor, Microsoft Learn
• Blazor forms and antiforgery, Microsoft Learn
• Handle errors in Blazor apps, Microsoft Learn
• Rate limiting middleware, Microsoft Learn
• Auditing NuGet packages for security vulnerabilities, Microsoft Learn