.NET MAUI Sicherheit: Complete Guide 2026

Warum Sicherheit in mobilen Apps oberste Priorität hat

Hand aufs Herz: Wie viel Zeit haben Sie bei Ihrem letzten .NET MAUI-Projekt wirklich in die Sicherheitsarchitektur investiert? Wenn die ehrliche Antwort „zu wenig" lautet, sind Sie damit definitiv nicht allein. Ich hab das selbst bei meinen ersten MAUI-Projekten erlebt — Sicherheit wird gerne als nachträglicher Gedanke behandelt, so nach dem Motto „das machen wir vor dem Release noch schnell". Aber genau diese Einstellung führt zu den Datenlecks und Sicherheitsvorfällen, die dann regelmäßig in den Schlagzeilen landen.

Mobile Apps operieren in einer grundlegend anderen Bedrohungslandschaft als Web-Anwendungen. Ihr Code läuft auf Geräten, die Sie nicht kontrollieren. Nutzer verbinden sich über unsichere WLANs. Angreifer können Ihre APK dekompilieren und jeden eingebetteten String lesen. Geräte werden gerootet oder gejailbreakt. Die OWASP Mobile Top 10 2024 dokumentieren die häufigsten Schwachstellen — von unzureichender Authentifizierung (M3) über unsichere Datenspeicherung (M9) bis hin zu mangelhafter Kryptographie (M10). Und jede einzelne davon ist in der Praxis ausnutzbar.

.NET MAUI liefert Ihnen ein starkes Cross-Platform-Framework, aber Sicherheit wird Ihnen nicht geschenkt. Sie müssen sie bewusst einbauen — von der Art, wie Sie Benutzer authentifizieren, über den Ort, an dem Sie Tokens speichern, bis hin zur Verifikation des Servers am anderen Ende der HTTPS-Verbindung.

Dieser Praxisleitfaden führt Sie durch den gesamten Sicherheits-Stack einer .NET MAUI-Anwendung. Wir behandeln OAuth 2.0 und OpenID Connect, Token-Management mit SecureStorage, biometrische Authentifizierung, Certificate Pinning, den Schutz von API-Schlüsseln, Code-Obfuskation und DSGVO-konforme Entwicklung. Jeder Abschnitt enthält lauffähige C#-Codebeispiele, die Sie direkt in Ihre Projekte übernehmen können.

Also, legen wir los.

Sichere Authentifizierung mit OAuth 2.0 und OIDC

Die Authentifizierung ist das Fundament jeder sicheren App. In der mobilen Welt gilt OAuth 2.0 mit PKCE (Proof Key for Code Exchange) in Kombination mit OpenID Connect als Goldstandard. Ältere Ansätze wie der Implicit Flow oder das lokale Speichern von Passwörtern? Die gelten inzwischen als unsicher und sollten nicht mehr verwendet werden.

Mobile Apps werden in der OAuth-Terminologie als „Public Clients" klassifiziert. Anders als serverseitige Anwendungen können sie kein Client Secret sicher aufbewahren — jeder kann Ihre App dekompilieren und es extrahieren. Der Authorization Code Flow mit PKCE löst dieses Problem elegant, indem bei jedem Authentifizierungsvorgang ein dynamisch generierter Code Verifier und Challenge verwendet wird. Selbst wenn ein Angreifer den Authorization Code abfängt, kann er ihn ohne den Code Verifier nicht gegen Tokens eintauschen.

MSAL.NET in .NET MAUI einrichten

Die Microsoft Authentication Library (MSAL.NET) ist die offizielle Bibliothek für die Authentifizierung gegen Microsoft Entra ID (ehemals Azure AD), Azure AD B2C und andere Microsoft-Identitätsplattformen. Seit Version 4.47.0 bietet MSAL.NET erstklassige .NET MAUI-Unterstützung und übernimmt die gesamte Komplexität von PKCE, Token-Caching, Silent Token Renewal und plattformspezifischer Browser-Integration. Ehrlich gesagt — das spart enorm viel Arbeit.

Installieren Sie zunächst das NuGet-Paket:

dotnet add package Microsoft.Identity.Client

Konfigurieren Sie anschließend Ihren Authentifizierungsdienst. Der Schlüssel liegt im Aufbau der IPublicClientApplication mit den korrekten plattformspezifischen Redirect-URIs:

using Microsoft.Identity.Client;

public class AuthService
{
    private readonly IPublicClientApplication _authClient;

    private const string ClientId = "ihre-client-id";
    private const string TenantId = "ihre-tenant-id";
    private const string Authority = $"https://login.microsoftonline.com/{TenantId}";

#if ANDROID
    private const string RedirectUri = $"msal{ClientId}://auth";
#elif IOS
    private const string RedirectUri = $"msal{ClientId}://auth";
#else
    private const string RedirectUri =
        "https://login.microsoftonline.com/common/oauth2/nativeclient";
#endif

    private readonly string[] _scopes =
        { "openid", "profile", "email", "offline_access" };

    public AuthService()
    {
        _authClient = PublicClientApplicationBuilder
            .Create(ClientId)
            .WithAuthority(Authority)
            .WithRedirectUri(RedirectUri)
            .WithIosKeychainSecurityGroup("com.ihrefirma.ihreapp")
            .Build();
    }
}

Der Anmeldefluss: Silent First, Interactive als Fallback

Die bewährte Praxis mit MSAL: Versuchen Sie immer zuerst eine stille Token-Akquisition. MSAL unterhält einen In-Memory-Token-Cache und gibt ein gecachtes Token zurück, wenn es noch gültig ist — oder erneuert es automatisch über das Refresh Token. Nur wenn kein gecachtes Konto existiert oder die stille Akquisition fehlschlägt, greift man auf eine interaktive Anmeldung zurück:

public async Task<AuthenticationResult?> SignInAsync()
{
    try
    {
        var accounts = await _authClient.GetAccounts();
        var firstAccount = accounts.FirstOrDefault();

        if (firstAccount != null)
        {
            try
            {
                return await _authClient
                    .AcquireTokenSilent(_scopes, firstAccount)
                    .ExecuteAsync();
            }
            catch (MsalUiRequiredException)
            {
                // Token abgelaufen und Refresh fehlgeschlagen
            }
        }

        return await _authClient
            .AcquireTokenInteractive(_scopes)
#if ANDROID
            .WithParentActivityOrWindow(Platform.CurrentActivity)
#elif IOS
            .WithSystemWebViewOptions(new SystemWebViewOptions
            {
                iOSHidePrivacyPrompt = true
            })
#endif
            .ExecuteAsync();
    }
    catch (MsalException ex)
    {
        System.Diagnostics.Debug.WriteLine($"MSAL-Fehler: {ex.Message}");
        return null;
    }
}

Plattformspezifische Konfiguration

MSAL benötigt auf jeder Plattform eine eigene Konfiguration, um den Authentifizierungs-Callback korrekt zu verarbeiten. Das ist leider etwas fummelig, aber notwendig.

Android: Deklarieren Sie in Ihrer AndroidManifest.xml eine Activity für den MSAL-Redirect. Zusätzlich müssen Sie in der MainActivity.cs das Aktivitätsergebnis weiterleiten:

<!-- AndroidManifest.xml -->
<activity
    android:name="microsoft.identity.client.BrowserTabActivity"
    android:configChanges="orientation|screenSize"
    android:exported="true">
    <intent-filter>
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <data
            android:host="auth"
            android:scheme="msalihre-client-id" />
    </intent-filter>
</activity>

// MainActivity.cs
protected override void OnActivityResult(
    int requestCode, Result resultCode, Intent? data)
{
    base.OnActivityResult(requestCode, resultCode, data);
    AuthenticationContinuationHelper
        .SetAuthenticationContinuationEventArgs(requestCode, resultCode, data);
}

iOS: Fügen Sie das URL-Schema in Ihre Info.plist ein und aktivieren Sie den Keychain-Zugriff in der Entitlements.plist:

<!-- Info.plist -->
<key>CFBundleURLTypes</key>
<array>
    <dict>
        <key>CFBundleURLSchemes</key>
        <array>
            <string>msalihre-client-id</string>
        </array>
    </dict>
</array>

Darüber hinaus bietet .NET MAUI mit dem integrierten WebAuthenticator eine providerunabhängige Alternative für OAuth-Flows mit Google, Apple oder eigenen Identity-Servern. Beachten Sie aber, dass WebAuthenticator derzeit keine Windows-Unterstützung bietet — für Desktop-Plattformen brauchen Sie eine separate Lösung.

Token-Management: Sicher speichern und aktualisieren

Nachdem die Authentifizierung steht, kommt die entscheidende Frage: Wohin mit den Tokens? Access Tokens und Refresh Tokens sind die Schlüssel zu Ihrer API — werden sie kompromittiert, hat ein Angreifer denselben Zugriff wie der legitimierte Nutzer.

Die Antwort: ausschließlich in den SecureStorage von .NET MAUI.

Tokens mit SecureStorage verwalten

Der folgende Service kapselt die gesamte Token-Verwaltung und stellt sicher, dass Tokens niemals im Klartext auf dem Gerät landen:

public class TokenStorageService
{
    private const string AccessTokenKey = "access_token";
    private const string RefreshTokenKey = "refresh_token";
    private const string TokenExpiryKey = "token_expiry";

    public async Task StoreTokensAsync(
        string accessToken,
        string refreshToken,
        DateTimeOffset expiry)
    {
        await SecureStorage.Default.SetAsync(AccessTokenKey, accessToken);
        await SecureStorage.Default.SetAsync(RefreshTokenKey, refreshToken);
        await SecureStorage.Default.SetAsync(
            TokenExpiryKey,
            expiry.ToUnixTimeSeconds().ToString());
    }

    public async Task<(string? AccessToken, string? RefreshToken,
        DateTimeOffset? Expiry)> GetTokensAsync()
    {
        var accessToken = await SecureStorage.Default.GetAsync(AccessTokenKey);
        var refreshToken = await SecureStorage.Default.GetAsync(RefreshTokenKey);
        var expiryStr = await SecureStorage.Default.GetAsync(TokenExpiryKey);

        DateTimeOffset? expiry = null;
        if (long.TryParse(expiryStr, out var unixSeconds))
        {
            expiry = DateTimeOffset.FromUnixTimeSeconds(unixSeconds);
        }

        return (accessToken, refreshToken, expiry);
    }

    public void ClearTokens()
    {
        SecureStorage.Default.Remove(AccessTokenKey);
        SecureStorage.Default.Remove(RefreshTokenKey);
        SecureStorage.Default.Remove(TokenExpiryKey);
    }

    public async Task<bool> HasValidTokenAsync()
    {
        var (accessToken, _, expiry) = await GetTokensAsync();
        return !string.IsNullOrEmpty(accessToken)
            && expiry.HasValue
            && expiry.Value > DateTimeOffset.UtcNow;
    }
}

Automatische Token-Erneuerung mit DelegatingHandler

Eine robuste Token-Strategie wartet nicht, bis ein API-Aufruf mit einem 401-Fehler fehlschlägt. Stattdessen prüft sie proaktiv die Token-Gültigkeit und erneuert das Token, bevor es abläuft. Das klingt aufwändig, ist aber mit einem DelegatingHandler überraschend elegant lösbar:

public class AuthenticatedHttpHandler : DelegatingHandler
{
    private readonly TokenStorageService _tokenStorage;
    private readonly AuthService _authService;
    private readonly SemaphoreSlim _refreshLock = new(1, 1);

    public AuthenticatedHttpHandler(
        TokenStorageService tokenStorage,
        AuthService authService)
    {
        _tokenStorage = tokenStorage;
        _authService = authService;
    }

    protected override async Task<HttpResponseMessage> SendAsync(
        HttpRequestMessage request,
        CancellationToken cancellationToken)
    {
        var (accessToken, _, expiry) = await _tokenStorage.GetTokensAsync();

        // Proaktiv erneuern, wenn Token in 2 Minuten abläuft
        if (expiry.HasValue &&
            expiry.Value < DateTimeOffset.UtcNow.AddMinutes(2))
        {
            await _refreshLock.WaitAsync(cancellationToken);
            try
            {
                // Erneute Prüfung nach Lock-Erwerb
                var (currentToken, _, currentExpiry) =
                    await _tokenStorage.GetTokensAsync();

                if (currentExpiry.HasValue &&
                    currentExpiry.Value < DateTimeOffset.UtcNow.AddMinutes(2))
                {
                    var result = await _authService.SignInAsync();
                    if (result != null)
                    {
                        accessToken = result.AccessToken;
                        await _tokenStorage.StoreTokensAsync(
                            result.AccessToken,
                            result.AccessToken,
                            result.ExpiresOn);
                    }
                }
                else
                {
                    accessToken = currentToken;
                }
            }
            finally
            {
                _refreshLock.Release();
            }
        }

        if (!string.IsNullOrEmpty(accessToken))
        {
            request.Headers.Authorization =
                new AuthenticationHeaderValue("Bearer", accessToken);
        }

        var response = await base.SendAsync(request, cancellationToken);

        if (response.StatusCode == System.Net.HttpStatusCode.Unauthorized)
        {
            _tokenStorage.ClearTokens();
            WeakReferenceMessenger.Default.Send(
                new SessionExpiredMessage());
        }

        return response;
    }
}

Das SemaphoreSlim-Pattern hier ist wichtig: Es verhindert, dass mehrere gleichzeitige API-Aufrufe parallel Token-Erneuerungen auslösen. Der erste Aufruf erneuert das Token, alle nachfolgenden nutzen das bereits erneuerte. Ohne diesen Lock hatte ich in einem Projekt mal das Problem, dass fünf parallele Requests fünf Refresh-Vorgänge gleichzeitig gestartet haben — das war nicht schön.

Empfohlene Token-Lebensdauern für mobile Apps:

Access Tokens: 5–15 Minuten. Kurze Lebensdauern begrenzen das Schadensfenster bei Kompromittierung.
Refresh Tokens: Tage bis Wochen. Ermöglichen nahtlose Re-Authentifizierung ohne erneute Anmeldung.
Refresh Token Rotation: Bei jeder Verwendung eines Refresh Tokens sollte der Server ein neues ausstellen und das alte invalidieren.

Biometrische Authentifizierung integrieren

Biometrische Authentifizierung fügt eine entscheidende Schutzschicht auf Geräteebene hinzu. Sie ersetzt nicht die serverseitige Authentifizierung — sie schützt den Zugriff auf gespeicherte Anmeldedaten und sensible App-Bereiche. Und mal ehrlich: Nutzer erwarten das heutzutage einfach in jeder App, die sensible Daten verarbeitet.

Die gute Nachricht: Mit der richtigen Bibliothek ist die Implementierung in .NET MAUI unkompliziert.

Plugin.Maui.Biometric einrichten

Das Plugin.Maui.Biometric NuGet-Paket bietet plattformübergreifende biometrische Authentifizierung für iOS, Android, macOS und Windows:

dotnet add package Plugin.Maui.Biometric

Registrieren Sie den Dienst in Ihrer MauiProgram.cs:

using Plugin.Maui.Biometric;

public static MauiApp CreateMauiApp()
{
    var builder = MauiApp.CreateBuilder();
    builder
        .UseMauiApp<App>()
        .ConfigureFonts(fonts =>
        {
            fonts.AddFont("OpenSans-Regular.ttf", "OpenSansRegular");
        });

    builder.Services.AddSingleton<IBiometric>(
        BiometricAuthenticationService.Default);

    return builder.Build();
}

Verfügbarkeit prüfen und Authentifizierung durchführen

Bevor Sie zur biometrischen Authentifizierung auffordern, prüfen Sie immer zuerst die Gerätefähigkeit. Nicht jedes Gerät unterstützt Biometrie, und manche Nutzer haben schlicht keine Fingerabdrücke oder Gesichtsdaten registriert:

public class BiometricService
{
    private readonly IBiometric _biometric;

    public BiometricService(IBiometric biometric)
    {
        _biometric = biometric;
    }

    public async Task<bool> AuthenticateAsync()
    {
        var availability = await _biometric.GetAvailabilityAsync();

        if (availability != BiometricAvailability.Available)
        {
            // Biometrie nicht verfügbar — Fallback auf PIN
            return false;
        }

        var request = new AuthenticationRequest
        {
            Title = "Identität bestätigen",
            NegativeText = "Passwort verwenden",
            AllowAlternativeAuthentication = true
        };

        var result = await _biometric.AuthenticateAsync(request);
        return result.Status == BiometricResponseStatus.Success;
    }
}

Plattformspezifische Berechtigungen

iOS: Fügen Sie den Schlüssel NSFaceIDUsageDescription in Ihre Info.plist ein. Ohne diesen Eintrag stürzt Ihre App beim Versuch einer Face-ID-Authentifizierung einfach ab (ja, wirklich — kein schöner Fehler, nur ein Crash):

<key>NSFaceIDUsageDescription</key>
<string>Wir verwenden Face ID, um Ihre Identität sicher zu verifizieren, bevor auf sensible Daten zugegriffen wird.</string>

Android: Fügen Sie die Biometrie-Berechtigung in Ihre AndroidManifest.xml ein:

<uses-permission android:name="android.permission.USE_BIOMETRIC" />

Biometrie mit Token-basierter Authentifizierung kombinieren

Die eigentliche Stärke zeigt sich in der Kombination. Verwenden Sie Biometrie als Zugangskontrolle zu gespeicherten Refresh Tokens und ermöglichen Sie so eine nahtlose, aber sichere Re-Authentifizierung:

public async Task<string?> GetAccessTokenWithBiometricAsync()
{
    // Schritt 1: Identität per Biometrie verifizieren
    var isAuthenticated = await _biometricService.AuthenticateAsync();
    if (!isAuthenticated)
    {
        return null;
    }

    // Schritt 2: Gespeichertes Refresh Token abrufen
    var refreshToken = await SecureStorage.Default.GetAsync("refresh_token");
    if (string.IsNullOrEmpty(refreshToken))
    {
        return null; // Kein gespeichertes Token — vollständige Anmeldung nötig
    }

    // Schritt 3: Refresh Token gegen neues Access Token tauschen
    return await ExchangeRefreshTokenAsync(refreshToken);
}

SecureStorage im Detail

Der SecureStorage von .NET MAUI ist Ihr primäres Werkzeug für die Speicherung sensibler Daten — Authentifizierungs-Tokens, API-Schlüssel, Verschlüsselungsschlüssel. Um fundierte Entscheidungen über seine Verwendung treffen zu können, sollten Sie verstehen, was unter der Haube passiert.

Plattformspezifische Implementierungen

Jede Plattform nutzt ihr eigenes natives Sicherheitssystem:

Android: Verwendet EncryptedSharedPreferences aus der AndroidX Security-Bibliothek. Schlüssel werden deterministisch verschlüsselt, Werte verwenden AES-256-GCM mit nicht-deterministischer Verschlüsselung. Der Master Key wird im Android Keystore gespeichert, der auf den meisten modernen Geräten hardware-gestützt ist.
iOS/macOS: Nutzt die System-Keychain, die auf Geräten mit Secure Enclave (iPhone 5S und neuer) hardware-gestützte Verschlüsselung bietet. Keychain-Einträge werden durch den Geräte-Passcode und biometrische Daten geschützt.
Windows: Verwendet den DataProtectionProvider, der Daten mit den Windows-Anmeldedaten des Benutzers verschlüsselt. Verschlüsselte Werte landen in ApplicationData.Current.LocalSettings.

SecureStorage vs. Preferences: Wann was verwenden?

Eine Frage, die ich ständig höre: Wann brauche ich SecureStorage und wann reichen Preferences? Die Antwort hängt von der Sensitivität der Daten ab:

SecureStorage: Für alle Daten, deren Offenlegung ein Sicherheitsrisiko darstellt — Tokens, Passwörter, API-Schlüssel, Verschlüsselungsschlüssel, personenbezogene Daten.
Preferences: Für nicht-sensible Anwendungseinstellungen — Theme-Auswahl, Spracheinstellung, UI-Präferenzen, Feature-Flags.

Eine einfache Faustregel: Wenn Sie sich fragen würden, ob ein Penetrationstester die Daten als „Finding" melden würde, gehören sie in den SecureStorage.

Einschränkungen und bewährte Praktiken

SecureStorage ist für kleine Schlüssel-Wert-Paare konzipiert. Für größere Datenmengen speichern Sie einen Verschlüsselungsschlüssel im SecureStorage und verschlüsseln damit Ihre Datendateien über standardmäßige Kryptographie-APIs:

public class SecureDataService
{
    private const string EncryptionKeyName = "data_encryption_key";

    public async Task<byte[]> GetOrCreateEncryptionKeyAsync()
    {
        var existingKey = await SecureStorage.Default.GetAsync(
            EncryptionKeyName);

        if (!string.IsNullOrEmpty(existingKey))
        {
            return Convert.FromBase64String(existingKey);
        }

        // Neuen 256-Bit-Schlüssel generieren
        var key = new byte[32];
        using var rng = RandomNumberGenerator.Create();
        rng.GetBytes(key);

        await SecureStorage.Default.SetAsync(
            EncryptionKeyName,
            Convert.ToBase64String(key));

        return key;
    }

    public async Task<byte[]> EncryptDataAsync(byte[] plaintext)
    {
        var key = await GetOrCreateEncryptionKeyAsync();
        using var aes = Aes.Create();
        aes.Key = key;
        aes.GenerateIV();

        using var encryptor = aes.CreateEncryptor();
        var encrypted = encryptor.TransformFinalBlock(
            plaintext, 0, plaintext.Length);

        // IV und verschlüsselte Daten zusammenfügen
        var result = new byte[aes.IV.Length + encrypted.Length];
        aes.IV.CopyTo(result, 0);
        encrypted.CopyTo(result, aes.IV.Length);

        return result;
    }
}

Ein paar Fallstricke, die man kennen sollte:

Android-Neuinstallation: Beim Deinstallieren und Neuinstallieren der App werden gespeicherte SecureStorage-Werte unzugänglich, da die Verschlüsselungsschlüssel neu generiert werden. Das hat mich beim ersten Mal ordentlich überrascht.
iOS-Persistenz: Keychain-Einträge überleben standardmäßig eine Neuinstallation. Gestalten Sie Ihren Token-Refresh-Flow so, dass er mit dieser Diskrepanz umgehen kann.
Backup-Verhalten: Auf Android werden SecureStorage-Daten nicht in Backups einbezogen. Planen Sie entsprechend für den Fall, dass Nutzer auf ein neues Gerät wechseln.
Null-Toleranz: Rechnen Sie immer damit, dass SecureStorage null zurückgibt — auch wenn Sie Daten zuvor gespeichert haben.

HTTPS und Certificate Pinning

HTTPS schützt Ihren Netzwerkverkehr vor Lauschangriffen, hat aber eine Schwachstelle: Die Vertrauenskette basiert auf Zertifizierungsstellen (CAs). Wenn ein Angreifer eine CA kompromittiert, ein Root-Zertifikat auf dem Gerät installiert oder ein Unternehmens-Proxy TLS-Interception durchführt, kann er Ihren „verschlüsselten" Datenverkehr mitlesen.

Das ist kein theoretisches Szenario. Es ist der Kern von Man-in-the-Middle-Angriffen, die in den OWASP Mobile Top 10 2024 unter M5 (Insecure Communication) aufgeführt sind.

Certificate Pinning eliminiert diesen Angriffsvektor, indem Sie festlegen, welchen Zertifikaten oder öffentlichen Schlüsseln Ihre App vertraut.

Implementierung mit Custom HttpMessageHandler

Der wartbarste Ansatz in .NET MAUI verwendet einen benutzerdefinierten HttpMessageHandler, der das Server-Zertifikat gegen Ihren erwarteten Public-Key-Hash validiert:

using System.Net.Security;
using System.Security.Cryptography;
using System.Security.Cryptography.X509Certificates;

public class CertificatePinningHandler : HttpClientHandler
{
    private readonly HashSet<string> _pinnedPublicKeyHashes;

    public CertificatePinningHandler(
        IEnumerable<string> pinnedHashes)
    {
        _pinnedPublicKeyHashes = new HashSet<string>(pinnedHashes);
        ServerCertificateCustomValidationCallback = ValidateCertificate;
    }

    private bool ValidateCertificate(
        HttpRequestMessage request,
        X509Certificate2? certificate,
        X509Chain? chain,
        SslPolicyErrors sslErrors)
    {
        if (certificate == null) return false;

        // Zuerst Standard-SSL-Validierung prüfen
        if (sslErrors != SslPolicyErrors.None) return false;

        // SHA-256-Hash des öffentlichen Schlüssels berechnen
        var publicKeyBytes = certificate.GetPublicKey();
        var hashBytes = SHA256.HashData(publicKeyBytes);
        var hashString = Convert.ToBase64String(hashBytes);

        return _pinnedPublicKeyHashes.Contains(hashString);
    }
}

Registrieren Sie den Pinning-Handler in Ihrem DI-Container:

builder.Services.AddHttpClient("SecureApi", client =>
{
    client.BaseAddress = new Uri("https://api.ihrdienst.com");
})
.ConfigurePrimaryHttpMessageHandler(() =>
    new CertificatePinningHandler(new[]
    {
        "IhrBase64KodierterPublicKeyHash1=",
        "IhrBase64KodierterPublicKeyHash2=" // Backup-Pin für Schlüsselrotation
    }));

Android: Deklaratives Pinning mit Network Security Config

Auf Android können Sie Certificate Pinning auch deklarativ über die Network Security Configuration konfigurieren. Erstellen Sie dazu die Datei Platforms/Android/Resources/xml/network_security_config.xml:

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config>
        <domain includeSubdomains="true">api.ihrdienst.com</domain>
        <pin-set expiration="2027-06-01">
            <pin digest="SHA-256">IhrBase64Pin1=</pin>
            <pin digest="SHA-256">IhrBase64Pin2=</pin>
        </pin-set>
    </domain-config>
</network-security-config>

Referenzieren Sie die Konfiguration in Ihrer AndroidManifest.xml:

<application
    android:networkSecurityConfig="@xml/network_security_config" />

iOS: Certificate Pinning mit TrustKit

Für iOS bietet TrustKit eine bewährte Lösung für Certificate Pinning. Konfigurieren Sie die Pins in Ihrer Info.plist:

<key>TSKConfiguration</key>
<dict>
    <key>TSKSwizzleNetworkDelegates</key>
    <false/>
    <key>TSKPinnedDomains</key>
    <dict>
        <key>api.ihrdienst.com</key>
        <dict>
            <key>TSKEnforcePinning</key>
            <true/>
            <key>TSKPublicKeyHashes</key>
            <array>
                <string>IhrBase64Pin1=</string>
                <string>IhrBase64Pin2=</string>
            </array>
        </dict>
    </dict>
</dict>

Unabhängig von der gewählten Methode: Verwenden Sie immer mindestens zwei Pins — einen primären und einen Backup-Pin. Wenn Ihr Zertifikat abläuft oder Sie Schlüssel rotieren müssen, verhindert der Backup-Pin, dass Ihre App vollständig funktionsunfähig wird. Setzen Sie zudem ein Ablaufdatum für das Pin-Set, um regelmäßige Überprüfungen zu erzwingen.

API-Schlüssel und Geheimnisse schützen

Eine der häufigsten Sicherheitssünden in der mobilen Entwicklung: das Hardcoding von API-Schlüsseln direkt im Quellcode. Es klingt offensichtlich, dass man das nicht tun sollte — und dennoch werden täglich tausende API-Schlüssel in dekompilierten Apps gefunden. Jeder String, den Sie in Ihren C#-Code einbetten, ist nach der Kompilierung im MSIL lesbar.

Warum Hardcoding keine Option ist

Selbst wenn Sie Ihren Code obfuskieren, bieten eingebettete Strings keinen echten Schutz. Angreifer können:

Die APK oder IPA dekompilieren und nach String-Mustern suchen
Den Netzwerkverkehr mit einem Proxy abfangen und API-Schlüssel aus Headern extrahieren
Den Speicher der laufenden App auslesen (auf gerooteten/gejailbreakten Geräten)

Das Server-Side-Proxy-Pattern

Die sicherste Lösung ist ein Server-Side-Proxy: Ihre mobile App kennt nur den Endpunkt Ihres eigenen Backends. Das Backend hält die eigentlichen API-Schlüssel für Drittanbieter-Dienste und leitet Anfragen weiter. So bleibt der Schlüssel auf dem Server — wo er hingehört:

// FALSCH: API-Schlüssel in der mobilen App
public class WeatherService
{
    private const string ApiKey = "sk-abc123geheim"; // NIEMALS!
    private readonly HttpClient _httpClient;

    public async Task<WeatherData> GetWeatherAsync(string city)
    {
        var response = await _httpClient.GetAsync(
            $"https://api.wetterdienst.com/v1/weather?city={city}" +
            $"&apikey={ApiKey}");
        // ...
    }
}

// RICHTIG: Anfrage über eigenes Backend leiten
public class WeatherService
{
    private readonly HttpClient _httpClient;

    public WeatherService(IHttpClientFactory httpClientFactory)
    {
        _httpClient = httpClientFactory.CreateClient("SecureApi");
    }

    public async Task<WeatherData> GetWeatherAsync(string city)
    {
        // Eigenes Backend hält den API-Schlüssel
        var response = await _httpClient.GetAsync(
            $"/api/weather?city={city}");
        return await response.Content
            .ReadFromJsonAsync<WeatherData>();
    }
}

Konfiguration über Umgebungsvariablen

Für Build-Konfigurationen, die zwischen Entwicklungs- und Produktionsumgebung variieren, nutzen Sie Umgebungsvariablen und Compile-Time-Konstanten. In .NET MAUI lässt sich das über Build-Properties lösen:

<!-- .csproj-Datei -->
<PropertyGroup Condition="'$(Configuration)' == 'Release'">
    <DefineConstants>$(DefineConstants);PRODUCTION</DefineConstants>
</PropertyGroup>

public static class AppConfig
{
    public static string ApiBaseUrl =>
#if PRODUCTION
        "https://api.produktion.ihrdienst.com";
#else
        "https://api.staging.ihrdienst.com";
#endif
}

Für sensiblere Werte, die auch nicht im Quellcode-Repository erscheinen sollen, nutzen Sie .NET User Secrets während der Entwicklung und sichere CI/CD-Variablen für den Build-Prozess. Geheimnisse sollten niemals in Git eingecheckt werden — auch nicht in appsettings.json.

Code-Obfuskation und Manipulationsschutz

.NET MAUI-Apps können dekompiliert werden, und jeder eingebettete String — API-Endpunkte, Konfigurationswerte, sogar die Struktur Ihres Authentifizierungsflusses — ist für Angreifer sichtbar. Obfuskation ersetzt keine solide Sicherheitsarchitektur, aber sie erhöht den Aufwand für einen Angreifer erheblich. Betrachten Sie es als ein zusätzliches Schloss an der Tür.

Dotfuscator für .NET MAUI

Dotfuscator von PreEmptive ist das etablierteste Obfuskations-Tool für .NET-Anwendungen. Es bietet:

Renaming: Umbenennung von Klassen, Methoden und Feldern in bedeutungslose Bezeichner
String Encryption: Verschlüsselung aller im Code eingebetteten Strings
Control Flow Obfuscation: Veränderung der Programmflusskontrolle zur Erschwerung der Analyse
Tamper Detection: Erkennung von Änderungen am kompilierten Code zur Laufzeit

Für Android-Builds bietet ProGuard/R8 zusätzliche Obfuskation auf der Java/Kotlin-Ebene. Aktivieren Sie es in Ihrer .csproj-Datei:

<PropertyGroup Condition="'$(Configuration)' == 'Release'">
    <RunProguard>true</RunProguard>
    <ProguardConfiguration>proguard.cfg</ProguardConfiguration>
</PropertyGroup>

Erkennung gerooteter/gejailbreakter Geräte

Gerootete Android-Geräte und gejailbreakte iOS-Geräte stellen ein erhöhtes Sicherheitsrisiko dar, da Angreifer auf diesen Geräten den App-Sandbox-Schutz umgehen können. Eine grundlegende Erkennung sieht so aus:

public static class DeviceSecurityCheck
{
    public static bool IsDeviceCompromised()
    {
#if ANDROID
        return CheckAndroidRoot();
#elif IOS
        return CheckiOSJailbreak();
#else
        return false;
#endif
    }

#if ANDROID
    private static bool CheckAndroidRoot()
    {
        // Prüfung auf bekannte Root-Indikatoren
        string[] rootPaths =
        {
            "/system/app/Superuser.apk",
            "/system/xbin/su",
            "/system/bin/su",
            "/sbin/su",
            "/data/local/xbin/su",
            "/data/local/bin/su"
        };

        foreach (var path in rootPaths)
        {
            if (File.Exists(path)) return true;
        }

        // Prüfung auf gefährliche Properties
        try
        {
            using var process = Java.Lang.Runtime.GetRuntime()
                .Exec(new[] { "which", "su" });
            using var reader = new Java.IO.BufferedReader(
                new Java.IO.InputStreamReader(process.InputStream));
            return !string.IsNullOrEmpty(reader.ReadLine());
        }
        catch
        {
            return false;
        }
    }
#endif

#if IOS
    private static bool CheckiOSJailbreak()
    {
        string[] jailbreakPaths =
        {
            "/Applications/Cydia.app",
            "/Library/MobileSubstrate/MobileSubstrate.dylib",
            "/bin/bash",
            "/usr/sbin/sshd",
            "/etc/apt",
            "/private/var/lib/apt/"
        };

        foreach (var path in jailbreakPaths)
        {
            if (File.Exists(path)) return true;
        }

        // Prüfung auf Schreibzugriff außerhalb der Sandbox
        try
        {
            File.WriteAllText("/private/jailbreak_test", "test");
            File.Delete("/private/jailbreak_test");
            return true;
        }
        catch
        {
            return false;
        }
    }
#endif
}

Wichtiger Hinweis: Root- und Jailbreak-Erkennung ist kein absoluter Schutz. Erfahrene Angreifer können Erkennungsmechanismen umgehen. Betrachten Sie die Erkennung als eine Schicht in Ihrer Defense-in-Depth-Strategie, nicht als alleinige Schutzmaßnahme. Mein Rat: Informieren Sie den Nutzer über die Risiken, anstatt die App komplett zu blockieren — das ist nutzerfreundlicher und auch rechtlich unkomplizierter.

Integritätsprüfungen zur Laufzeit

Zusätzlich zur Geräteprüfung können Sie die Integrität Ihrer App zur Laufzeit überprüfen. Das erkennt, ob jemand Ihre App manipuliert hat — etwa um Lizenzprüfungen zu entfernen oder API-Endpunkte zu ändern:

public static class AppIntegrityCheck
{
    public static bool VerifyAppSignature()
    {
#if ANDROID
        try
        {
            var context = Android.App.Application.Context;
            var packageInfo = context.PackageManager?
                .GetPackageInfo(
                    context.PackageName ?? string.Empty,
                    Android.Content.PM.PackageInfoFlags.SigningCertificates);

            var signatures = packageInfo?.SigningInfo
                ?.GetApkContentsSigners();

            if (signatures == null || signatures.Length == 0)
                return false;

            var certBytes = signatures[0].ToByteArray();
            var hash = SHA256.HashData(certBytes);
            var currentHash = Convert.ToBase64String(hash);

            // Vergleich mit erwartetem Hash
            const string expectedHash = "IhrErwarteterSignaturHash=";
            return currentHash == expectedHash;
        }
        catch
        {
            return false;
        }
#else
        return true;
#endif
    }
}

Datenschutz: DSGVO-konforme App-Entwicklung

Für den europäischen Markt — und ganz besonders für den deutschsprachigen Raum — ist die Einhaltung der DSGVO nicht optional. Verstöße können Bußgelder von bis zu 20 Millionen Euro oder 4 % des weltweiten Jahresumsatzes nach sich ziehen. Das sind keine theoretischen Zahlen; die Behörden setzen das durch.

Aber jenseits der rechtlichen Konsequenzen ist Datenschutz auch ein Vertrauensfaktor: Nutzer, die wissen, dass ihre Daten respektvoll behandelt werden, bleiben Ihrer App treu.

Privacy by Design in .NET MAUI

Die DSGVO fordert „Datenschutz durch Technikgestaltung" (Privacy by Design). Das bedeutet konkret, dass Datenschutz von Anfang an in die Architektur Ihrer App eingebaut sein muss — nicht nachträglich als Pflaster aufgeklebt wird:

Datenminimierung: Erheben Sie nur die Daten, die für den jeweiligen Zweck tatsächlich erforderlich sind. Fragen Sie sich bei jedem Datenfeld: Brauchen wir das wirklich?
Zweckbindung: Verwenden Sie erhobene Daten ausschließlich für den Zweck, für den die Einwilligung erteilt wurde.
Speicherbegrenzung: Legen Sie fest, wie lange Daten aufbewahrt werden, und löschen Sie sie automatisch nach Ablauf der Frist.
Transparenz: Informieren Sie Nutzer klar und verständlich darüber, welche Daten erhoben werden und warum.

Einwilligungsmanagement implementieren

Bevor Sie personenbezogene Daten verarbeiten, brauchen Sie eine informierte Einwilligung des Nutzers. Hier ein Consent-Management, das die Einwilligungen nachvollziehbar speichert:

public class ConsentManager
{
    private const string AnalyticsConsentKey = "consent_analytics";
    private const string CrashReportingConsentKey = "consent_crash";
    private const string ConsentTimestampKey = "consent_timestamp";

    public async Task<bool> HasUserConsentedAsync(string purpose)
    {
        var consent = await SecureStorage.Default.GetAsync(purpose);
        return consent == "true";
    }

    public async Task SetConsentAsync(string purpose, bool granted)
    {
        await SecureStorage.Default.SetAsync(
            purpose,
            granted.ToString().ToLower());
        await SecureStorage.Default.SetAsync(
            ConsentTimestampKey,
            DateTimeOffset.UtcNow.ToString("O"));
    }

    public async Task<bool> CanCollectAnalyticsAsync()
    {
        return await HasUserConsentedAsync(AnalyticsConsentKey);
    }

    public async Task<bool> CanReportCrashesAsync()
    {
        return await HasUserConsentedAsync(CrashReportingConsentKey);
    }

    public async Task RevokeAllConsentsAsync()
    {
        SecureStorage.Default.Remove(AnalyticsConsentKey);
        SecureStorage.Default.Remove(CrashReportingConsentKey);
        SecureStorage.Default.Remove(ConsentTimestampKey);
    }
}

Sichere Datenlöschung

Die DSGVO gewährt Nutzern das „Recht auf Löschung" (Art. 17). Wenn ein Nutzer die Löschung seiner Daten verlangt, müssen Sie in der Lage sein, alle personenbezogenen Daten vollständig zu entfernen — lokal und serverseitig. Das klingt einfach, kann in der Praxis aber überraschend knifflig werden:

public class DataDeletionService
{
    private readonly HttpClient _httpClient;
    private readonly TokenStorageService _tokenStorage;

    public DataDeletionService(
        IHttpClientFactory httpClientFactory,
        TokenStorageService tokenStorage)
    {
        _httpClient = httpClientFactory.CreateClient("SecureApi");
        _tokenStorage = tokenStorage;
    }

    public async Task<bool> RequestFullDataDeletionAsync()
    {
        try
        {
            // 1. Serverseitige Löschung anfordern
            var response = await _httpClient.DeleteAsync(
                "/api/user/data");

            if (!response.IsSuccessStatusCode)
                return false;

            // 2. Lokale sensible Daten löschen
            _tokenStorage.ClearTokens();
            SecureStorage.Default.RemoveAll();

            // 3. Lokale Datenbank bereinigen
            var dbPath = Path.Combine(
                FileSystem.AppDataDirectory, "app.db");
            if (File.Exists(dbPath))
            {
                File.Delete(dbPath);
            }

            // 4. Cache-Verzeichnis leeren
            var cacheDir = FileSystem.CacheDirectory;
            if (Directory.Exists(cacheDir))
            {
                foreach (var file in Directory.GetFiles(cacheDir))
                {
                    File.Delete(file);
                }
            }

            // 5. Preferences zurücksetzen
            Preferences.Default.Clear();

            return true;
        }
        catch (Exception ex)
        {
            System.Diagnostics.Debug.WriteLine(
                $"Datenlöschung fehlgeschlagen: {ex.Message}");
            return false;
        }
    }
}

Vermeidung von Datenlecks

Achten Sie auch auf die weniger offensichtlichen Stellen, an denen personenbezogene Daten unbeabsichtigt landen können (diese werden gerne übersehen):

Screenshots und App Switcher: iOS und Android erstellen Screenshots der App für den App-Switcher. Sensible Bildschirme sollten vor dem Wechsel in den Hintergrund überdeckt werden.
Tastatur-Cache: Textfelder mit sensiblen Daten sollten den Tastatur-Cache deaktivieren, damit eingegebene Daten nicht im Wörterbuch gespeichert werden.
Debug-Logs: Stellen Sie sicher, dass Release-Builds keine personenbezogenen Daten in Logs ausgeben. Verwenden Sie bedingte Kompilierung oder Log-Level-Konfiguration.
Clipboard: Warnen Sie Nutzer, wenn sie sensible Daten kopieren, und leeren Sie das Clipboard nach einer gewissen Zeit automatisch.

// Sensiblen Bildschirm beim Wechsel in den Hintergrund schützen
public partial class SensitivePage : ContentPage
{
    private readonly BoxView _privacyOverlay;

    public SensitivePage()
    {
        InitializeComponent();

        _privacyOverlay = new BoxView
        {
            Color = Colors.White,
            IsVisible = false,
            InputTransparent = false
        };

        // Overlay als oberstes Element hinzufügen
        if (Content is Grid grid)
        {
            Grid.SetRowSpan(_privacyOverlay, grid.RowDefinitions.Count);
            Grid.SetColumnSpan(_privacyOverlay, grid.ColumnDefinitions.Count);
            grid.Children.Add(_privacyOverlay);
        }
    }

    protected override void OnDisappearing()
    {
        base.OnDisappearing();
        _privacyOverlay.IsVisible = true;
    }

    protected override void OnAppearing()
    {
        base.OnAppearing();
        _privacyOverlay.IsVisible = false;
    }
}

Sicherheits-Checkliste für den App-Store-Release

Bevor Sie Ihre .NET MAUI-App in den App Store oder Google Play Store einreichen, arbeiten Sie diese Checkliste ab. Jeder Punkt adressiert eine reale Schwachstelle, die in produktiven mobilen Apps schon ausgenutzt wurde. Drucken Sie sie sich aus, hängen Sie sie an den Monitor — wie auch immer es bei Ihnen am besten funktioniert.

Authentifizierung und Autorisierung

OAuth 2.0 mit PKCE: Verwenden Sie den Authorization Code Flow mit PKCE über den System-Browser — speichern Sie niemals Passwörter lokal.
Token-Speicherung: Alle Tokens ausschließlich in SecureStorage, niemals in Preferences oder Plain-Text-Dateien.
Token-Erneuerung: Implementieren Sie proaktive Token-Erneuerung vor Ablauf, nicht erst nach einem 401-Fehler.
Session-Management: Stellen Sie sicher, dass die Abmeldung alle gecachten Tokens und Session-Daten vollständig löscht.
Biometrisches Gating: Fordern Sie biometrische Verifikation beim Zugriff auf gespeicherte Anmeldedaten beim App-Neustart.

Netzwerksicherheit

TLS-Mindestversion: Erzwingen Sie TLS 1.2 oder höher. Deaktivieren Sie alle unsicheren Protokolle.
Certificate Pinning: Mindestens zwei Pins (primär + Backup) mit einem ablaufbasierten Rotationsplan.
Kein HTTP-Fallback: Stellen Sie sicher, dass kein Netzwerkverkehr über unverschlüsselte HTTP-Verbindungen läuft.
Auto-Redirect deaktivieren: Setzen Sie AllowAutoRedirect = false auf dem HttpClient, um Redirect-basierte Angriffe zu verhindern.

Datensicherheit

Keine Hardcoded Secrets: Kein API-Schlüssel, Client Secret oder Passwort darf im Quellcode eingebettet sein.
Datenbank-Verschlüsselung: Verwenden Sie SQLCipher oder vergleichbare Lösungen für lokale Datenbanken mit sensiblen Daten.
Sichere Löschung: Implementieren Sie vollständige Datenlöschung (lokal und serverseitig) für das DSGVO-Recht auf Löschung.
Backup-Schutz: Schließen Sie sensible Daten von automatischen Backups aus.

Code-Schutz

Obfuskation: Aktivieren Sie Code-Obfuskation für Release-Builds (Dotfuscator, ProGuard/R8).
Debug-Schutz: Deaktivieren Sie Debug-Logging und ausführliche Fehlermeldungen in Release-Builds.
Root/Jailbreak-Erkennung: Implementieren Sie eine Erkennung kompromittierter Geräte und informieren Sie den Nutzer.
Integritätsprüfung: Verifizieren Sie die App-Signatur zur Laufzeit, um Manipulationen zu erkennen.

Datenschutz und Compliance

Einwilligungsmanagement: Holen Sie nachweisbare Einwilligungen ein, bevor Sie Daten verarbeiten.
Datenschutzerklärung: Stellen Sie eine verständliche, aktuelle Datenschutzerklärung bereit.
Datenminimierung: Erheben und speichern Sie nur die Daten, die tatsächlich benötigt werden.
Dependency-Audit: Scannen Sie regelmäßig NuGet-Abhängigkeiten auf bekannte Schwachstellen mit dotnet list package --vulnerable.

Vor-Release-Prüfungen

# Schwachstellen in Abhängigkeiten prüfen
dotnet list package --vulnerable --include-transitive

# Release-Build erstellen und testen
dotnet build -c Release

# Sicherstellen, dass keine Debug-Symbole im Release sind
dotnet publish -c Release -f net10.0-android
dotnet publish -c Release -f net10.0-ios

Führen Sie zusätzlich einen manuellen Penetrationstest durch oder nutzen Sie automatisierte Security-Scanner wie MobSF (Mobile Security Framework), um Ihre fertige APK oder IPA auf bekannte Schwachstellen zu prüfen.

Fazit

Sicherheit in mobilen Apps ist keine Funktion, die man am Ende draufschraubt — sie ist eine architektonische Entscheidung, die beeinflusst, wie Sie alles bauen. Vom Anmeldebildschirm bis zum API-Client. Die hier vorgestellten Muster — MSAL-basierte Authentifizierung, biometrische Verifikation, sichere Token-Speicherung, Certificate Pinning, API-Schlüssel-Schutz, Code-Obfuskation und DSGVO-konforme Datenverarbeitung — bilden zusammen eine Defense-in-Depth-Strategie, die Ihre Nutzer gegen reale Bedrohungen schützt.

Die wichtigsten Erkenntnisse nochmal zusammengefasst:

Verwenden Sie bewährte Bibliotheken: MSAL.NET für Identity-Provider-Integration, SecureStorage für sensible Daten, Plugin.Maui.Biometric für biometrische Authentifizierung. Jedes dieser Tools existiert, weil Sicherheitsexperten bereits die Randfälle und Fehlermodi durchdacht haben, die Sie sonst mühsam selbst entdecken müssten.
Schichten Sie Ihre Verteidigung: Keine einzelne Sicherheitsmaßnahme ist unüberwindbar. Die Kombination aus sicherer Authentifizierung, verschlüsselter Speicherung, Netzwerkschutz und Code-Härtung macht Angriffe exponentiell schwieriger.
Denken Sie an den Datenschutz: Gerade im deutschsprachigen Raum ist DSGVO-Konformität nicht nur rechtliche Pflicht, sondern auch Vertrauenskapital. Privacy by Design sollte von der ersten Zeile Code an mitgedacht werden.
Testen Sie Ihre Sicherheit: Eine Sicherheitsarchitektur, die nie getestet wurde, bietet nur Scheinsicherheit. Nutzen Sie automatisierte Scanner, manuelle Penetrationstests und regelmäßige Dependency-Audits.

Fangen Sie mit Authentifizierung und Token-Management an, und fügen Sie dann Biometrie, Certificate Pinning und Code-Schutz hinzu — je nachdem, was das Bedrohungsmodell Ihrer App erfordert. .NET MAUI 10 bietet mit verbesserter NativeAOT-Unterstützung, dem XAML-Source-Generator und tieferer Integration plattformnativer Sicherheitsfunktionen die besten Voraussetzungen dafür.

Und zum Schluss noch das: Die sicherste mobile App ist eine, bei der Sicherheitsentscheidungen für den Nutzer unsichtbar sind. Wenn Ihre Auth-Flows reibungslos funktionieren, Ihre biometrischen Prompts zur richtigen Zeit kommen und Ihre Token-Erneuerungen nahtlos ablaufen — dann haben Sie beides erreicht: Sicherheit und eine hervorragende Nutzererfahrung. Genau das sollte das Ziel sein.