Kann eine Appein Geheimnis bewahren?

01 /Die kurze Antwort: Geh davon aus, dass der Client einsehbar ist

Mit der Veröffentlichung einer Android- oder iOS-App erhält jeder Nutzer eine Kopie des ausführbaren Codes und der Ressourcen. Den ursprünglichen Quellcode bekommt er nicht sauber sortiert, doch gängige Werkzeuge finden Zeichenketten, Konfigurationsdateien, Endpunkte und eine brauchbare Annäherung an die Programmstruktur. Um nach einem Token zu suchen oder eine Anfrage nachzubauen, muss niemand die gesamte App rekonstruieren.

Obfuskation bleibt sinnvoll: Sie entfernt sprechende Namen und macht die Analyse aufwendiger. Sie ist eine Hürde, kein Tresor. Einen Wert, den die App lesen muss, kann irgendwann auch jemand lesen, der das Gerät kontrolliert. Die robuste Regel lautet deshalb: Entwirf den Client als einsehbar und belasse die eigentliche Befugnis auf einem System, das du kontrollierst.

02 /Was eine dekompilierte App tatsächlich verrät

Der erste Durchgang ist meist unspektakulär. Man entpackt die Anwendung, listet ihre Ressourcen und durchsucht die enthaltenen Texte. So tauchen Serveradressen, Analyse-IDs, die Firebase-Konfiguration, Feature-Flags oder Zugangsdaten auf, die jemand in eine Build-Datei kopiert hat. Danach lassen sich die Anfragen der App beobachten. Hängt eine privilegierte Aktion nur von einem Wert im Client ab, liegt das Problem nicht beim besonders schlauen Decompiler, sondern an der falsch gesetzten Vertrauensgrenze.

Zur Laufzeit gespeicherte Daten brauchen dieselbe Sorgfalt. Ein Token für den angemeldeten Nutzer muss das Gerät erreichen; es für immer unsichtbar zu machen, ist nicht das Ziel. Es sollte eng begrenzt und kurzlebig sein, im geschützten Speicher der Plattform liegen, über TLS übertragen werden und auf dem Server bei jeder Anfrage nur die Rechte dieses Nutzers gewähren.

Aufwand ist nicht dasselbe wie Schutz. Einen Key auf mehrere Zeichenketten zu verteilen, zu kodieren oder erst nach dem Start zu laden, kann eine einfache Suche erschweren. Bei seiner Verwendung muss der vollständige Wert dennoch vorhanden sein. Solche Techniken bremsen massenhaftes Auslesen, verwandeln aber kein geteiltes Geheimnis in ein privates.

03 /Die Ausnahme beim Firebase-API-Key – und was sie nicht entschuldigt

Wer eine Android-App mit Firebase öffnet, findet in google-services.json meist einen API-Key; eine Apple-App enthält die entsprechende Konfiguration. Viele Prüfberichte markieren ihn als Fund. Firebase beschreibt diese Keys jedoch als bewusst öffentlich, solange sie auf Firebase-APIs beschränkt sind. Sie identifizieren das Projekt. Sie berechtigen einen Nutzer nicht dazu, Firestore, Realtime Database oder Cloud Storage zu lesen.

Die eigentlichen Schlösser sind Firebase Security Rules, angewandt auf den Anmeldestatus des Nutzers. App Check liefert ein weiteres Signal: Unterstützte Dienste können damit Verkehr ablehnen, der nicht von einer bestätigten Instanz deiner App stammt. Den Firebase-Key zu verstecken ersetzt keine dieser Kontrollen.

Die Unterscheidung ist wichtig. Im selben Google-Cloud-Projekt können andere Keys liegen, bei denen Nutzung oder Kosten tatsächlich am Schlüssel hängen. Ein Key für Karten, Zahlungen, E-Mail oder eine generative KI-API kann für einen Angreifer wertvoll sein. Trenne die Keys, beschränke jeden auf die vorgesehene API und Anwendung, setze sinnvolle Kontingente und führe jeden Dienst, der ein echtes Geheimnis verlangt, über deinen Server.

04 /Die Sicherheitsentscheidung gehört auf den Server

Stell dir eine fiktive Buchungs-App vor, die freie Termine zeigt und Kunden einen davon reservieren lässt. Die App darf die öffentliche API-Adresse kennen und ein Token des angemeldeten Kunden besitzen. Sie darf nicht selbst entscheiden, ob der Termin noch frei ist, ihren eigenen Preis setzen oder den Zahlungsdienst mit deinem privaten Key aufrufen.

Stattdessen nimmt der Server die Anfrage an, prüft Nutzer, Verfügbarkeit und aktuellen Preis, führt die privilegierte Aktion mit einem serverseitigen Zugang aus und gibt nur das Ergebnis zurück. Das Beispiel ist erfunden, die Grenze bleibt aber dieselbe – im Kundenportal, in der Lager-App oder im Abo-Produkt.

Prüfungen im Client verbessern weiterhin die Bedienung: einen ungültigen Button sperren, ein falsches Datum erkennen oder erklären, warum etwas nicht verfügbar ist. Jede sicherheitsrelevante Prüfung wird auf dem Server wiederholt, wo eine veränderte App sie nicht einfach überspringen kann.

05 /Was App Check, Play Integrity und App Attest beitragen

Autorisierung beantwortet, ob dieser Nutzer diese Aktion ausführen darf. App-Integrität beantwortet eine andere Frage: Scheint die Anfrage von einer echten, unveränderten Instanz der App zu kommen? Firebase App Check kann dazu unter Android Play Integrity und auf Apple-Plattformen App Attest oder DeviceCheck einsetzen und das Signal an Firebase-Dienste oder dein eigenes Backend weitergeben.

Das hilft gegen automatisierten Missbrauch, kopierte Clients und einen Teil des Verkehrs veränderter Apps. Ein unfehlbarer Beweis ist es nicht. Geräte können die Technik nicht unterstützen oder kompromittiert sein, der Attestierungsdienst kann ausfallen und ein böswilliger Nutzer kann eine echte App bedienen. Führe die Erzwingung beobachtet ein, bestimme das Verhalten bei Ausfällen und behalte normale Authentifizierung, Autorisierung, Ratenbegrenzung und Protokollierung bei.

Setze stärkere Prüfungen an wertvollen Stellen ein, statt jeden harmlosen Bildschirm zur Festung zu machen: eine Aktion einlösen, eine teure KI-Anfrage auslösen, bezahlte Inhalte laden oder ein Zahlungskonto ändern sind bessere Kandidaten als ein öffentlicher Katalog.

06 /Eine praktische Prüfung vor der Veröffentlichung

Untersuche vor dem Release dasselbe Artefakt, das Nutzer installieren – nicht nur das Quellcode-Repository. Suche im fertigen Paket nach Zugangsdaten und privatem Material; liste jeden angesprochenen Dienst auf; bestätige, dass jeder Key bewusst öffentlich oder auf das Minimum beschränkt ist; und teste wichtige Anfragen außerhalb der vorgesehenen App-Oberfläche.

Prüfe die Autorisierung anschließend mit zwei normalen Konten. Kann eines durch Ändern einer ID Datensätze des anderen lesen oder bearbeiten? Kann eines einen administrativen Endpunkt aufrufen? Werden bei Firebase Rules abgelehnte Fälle ebenso getestet wie der Normalfall? Prüfe zuletzt Protokolle, Kontingente und Warnungen: Eine Kontrolle, die du in Produktion nicht beobachten kannst, ist schwer zu beurteilen.

• Keine Service-Account-Dateien, Signaturgeheimnisse, Zahlungs-Secrets oder privaten Schlüssel im Paket.
• Jeder Client-Key hat einen Verantwortlichen, einen Zweck, Einschränkungen und einen Rotationsplan.
• Der Server prüft Identität, Besitz, Rollen, Preise und Ansprüche erneut.
• Firebase Rules sperren standardmäßig und haben Emulator-Tests für erlaubte und abgelehnte Anfragen.
• App-Attestierung ergänzt Authentifizierung und Autorisierung, ersetzt sie aber nie.
• Ratenlimits, Budgets und Warnungen machen Missbrauch sichtbar, bevor die Rechnung eintrifft.

07 /Wenn du in einer veröffentlichten App ein echtes Geheimnis findest

Behandle den Wert als offengelegt. Widerrufe oder rotiere ihn zuerst; nutze das sichere Übergabeverfahren des Anbieters, falls ein sofortiger Wechsel die Produktion unterbrechen würde. Prüfe Zugriffsprotokolle, Abrechnung und Änderungen mit diesen Zugangsdaten, bewahre die nötigen Spuren zur zeitlichen Einordnung auf und informiere die zuständigen Personen, falls Daten oder Konten betroffen sein könnten.

Die dauerhafte Lösung liegt in der Architektur: Setze den privilegierten Aufruf hinter einen Server oder eine verwaltete Funktion, autorisiere dort den Nutzer und gib dieser Laufzeit nur die nötigen Rechte. Eine neue App-Version mit kreativer verschleiertem Geheimnis startet nur denselben Countdown von vorn.