Blazor-beveiliging: 12 punten om te controleren voor de livegang

De meeste beveiligingsincidenten in bedrijfsapplicaties zijn niet slim. Een sleutel in de repository, een token dat nooit verloopt, een scherm dat een knop verbergt maar niet de actie erachter. Blazor komt met verstandige standaardinstellingen, maar laat schermcode en servercode bijna hetzelfde lijken, en precies daar zitten de makkelijke fouten.

Hier zijn twaalf controles die de moeite waard zijn voordat een Blazor-applicatie live gaat, of vóór de volgende audit. Sommige gelden overal, andere alleen voor een bepaalde rendermodus.

Overal

1. Autorisatie hoort in de service, niet alleen in het scherm

AuthorizeView bepaalt wat de gebruiker ziet. Het bepaalt niet wat de gebruiker mag doen.

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

De knop verbergen is goede gebruikerservaring, maar de bescherming moet in de methode zitten die het werk doet, zodat die geldt welk scherm, welke API of welke toekomstige ontwikkelaar haar ook aanroept:

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);
    }
}

Pagina’s worden beschermd met @attribute [Authorize], gevoelige acties met een policy in de service. Allebei, niet het een of het ander. Dezelfde regel geldt voor een AI-assistent in de applicatie.

2. Geen secrets in de repository

Connection strings, API-sleutels en certificaten horen in Azure Key Vault of in de instellingen van de hostingomgeving, en lokaal in Secret Manager, niet in appsettings.json. Is een sleutel ooit gecommit, dan is verwijderen niet genoeg, want hij blijft in de git-geschiedenis. Hij moet worden vervangen.

3. Tokens en sleutels die verlopen

API-sleutels zonder vervaldatum en sessies die maanden duren, zijn een open deur die niemand zich herinnert. Elke sleutel heeft een eigenaar, een vervaldatum en een manier om hem in te trekken nodig.

4. Bekende kwetsbaarheden in NuGet-pakketten

Sinds de .NET 8 SDK waarschuwt NuGet bij het herstellen van pakketten voor pakketten met bekende kwetsbaarheden. Die waarschuwingen mogen niet worden onderdrukt en vergeten. Voor oudere applicaties laat onze gratis tool voor .NET Framework-migratie zien welke van uw pakketten bekende kwetsbaarheden hebben.

5. Ruwe HTML alleen uit betrouwbare bronnen

Blazor codeert alles wat het toont, zodat tekst die een gebruiker typt geen script kan worden. De uitzondering is MarkupString, dat HTML toont zoals het is. Komt die HTML van gebruikers, uit e-mails of externe systemen, dan moet hij eerst worden opgeschoond.

6. Gedetailleerde fouten alleen tijdens ontwikkeling

DetailedErrors stuurt de volledige fout met details naar de browser. Op de computer van een ontwikkelaar is dat handig, in productie een cadeau voor een aanvaller. In productie krijgt de gebruiker een korte melding en gaan de details naar de log, bijvoorbeeld naar Application Insights.

7. Limieten voor inloggen en zware operaties

Inloggen, wachtwoordherstel en exports die de database zwaar belasten, hebben een limiet nodig op hoeveel verzoeken een gebruiker of adres mag sturen. ASP.NET Core heeft dit ingebouwd met AddRateLimiter.

8. Beveiligingsheaders en CSP

Een Content Security Policy vertelt de browser welke scripts hij mag uitvoeren. Blazor heeft eigen eisen: een WebAssembly-applicatie heeft wasm-unsafe-eval in de policy nodig. Stel de policy bewust in en test haar, in plaats van haar weg te laten omdat “er iets niet meer werkte”.

Statische formulieren

9. Bescherming tegen vervalste verzoeken (antiforgery)

In een Blazor Web App zijn formulieren die op de server worden gerenderd beschermd tegen cross-site request forgery als de applicatie app.UseAntiforgery() aanroept. EditForm voegt het token zelf toe, een gewone HTML-<form> heeft de component <AntiforgeryToken /> nodig.

Interactive Server

10. Verhoog de verbindingslimieten niet blind

Bij Interactive Server houdt elke gebruiker een verbinding en geheugen op de server vast. Blazor heeft limieten op berichtgrootte en op hoeveel het per gebruiker buffert, en die verhogen “omdat een upload mislukte” opent de weg om de server uit te putten. Grote bestanden horen in een aparte upload, niet in één enorm bericht. Hoe geheugen per gebruiker optelt, leest u in het artikel over trage Blazor-applicaties.

WebAssembly

11. Niets geheims in de client

Alles wat een WebAssembly-applicatie bevat, wordt naar de browser gedownload: de code, de configuratie en de bibliotheken. Microsoft is duidelijk dat connection strings, sleutels, wachtwoorden en privécode daar nooit mogen staan. Autorisatiecontroles in de browser kunnen worden omzeild, dus elke API moet de rechten op de server opnieuw controleren.

12. Tokens blijven op de server

Toegangstokens in de lokale opslag van de browser zijn een makkelijk doelwit. De aanpak die Microsoft aanbeveelt voor Blazor Web Apps is het Backend for Frontend-patroon: de server bewaart de tokens en praat met de API’s, en de browser krijgt alleen een veilige cookie.

De checklist in één tabel

#	Controle	Geldt voor
1	Autorisatie in services, niet alleen in het scherm	Overal
2	Geen secrets in de repository	Overal
3	Sleutels en tokens die verlopen	Overal
4	Geen bekende kwetsbaarheden in NuGet-pakketten	Overal
5	MarkupString alleen voor betrouwbare HTML	Overal
6	Gedetailleerde fouten uit in productie	Overal
7	Limieten voor inloggen en zware operaties	Overal
8	Bewuste CSP en beveiligingsheaders	Overal
9	Antiforgery voor formulieren	Statische formulieren
10	Verbindingslimieten blijven staan	Interactive Server
11	Niets geheims in de client	WebAssembly
12	Tokens op de server (BFF)	WebAssembly

Welke rendermodus bij welk scherm past en wat dat voor de beveiliging betekent, leest u in Blazor Server vs WebAssembly vs Auto.

Hoe wij werken

Wij controleren Blazor- en .NET-applicaties precies langs deze lijst en lossen op wat we vinden, van autorisatie die alleen in het scherm bestond tot sleutels die in de repository terecht zijn gekomen. U krijgt een geprioriteerde lijst met risico’s, van wat deze week opgelost moet worden tot wat kan wachten. Meer over ons werk met Blazor, en de eerste stap is een gratis gesprek van 30 minuten.

Bronnen

• 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