Welche Zugangsdaten gehören nicht in eine App?

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 erschwert die Analyse, indem sie etwa aussagekräftige Namen aus dem Code entfernt. Sie kann Werte, die eine App lesen muss, aber nicht zuverlässig vor jemandem verbergen, der das Gerät kontrolliert. Gehe deshalb davon aus, dass der Client untersucht werden kann, und prüfe Berechtigungen auf dem Server.

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

Bei einer Untersuchung werden häufig zunächst das App-Paket entpackt, seine Ressourcen aufgelistet und enthaltene Texte durchsucht. Dabei lassen sich beispielsweise Serveradressen, Analyse-IDs, Firebase-Konfiguration, Funktionsschalter und versehentlich eingebettete Zugangsdaten finden. Auch die Anfragen der App können untersucht werden. Eine privilegierte Aktion darf deshalb nicht allein von einem Wert abhängen, der in jeder App-Kopie enthalten ist.

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 /Warum ein Firebase-API-Key öffentlich sein kann

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.

Den Datenzugriff regeln Firebase Security Rules anhand des Anmeldestatus und der Berechtigungen. App Check liefert ein zusätzliches Signal: Unterstützte Dienste können damit Anfragen ablehnen, die nicht von einer bestätigten App-Instanz stammen. Diese Kontrollen bleiben auch bei einem versteckten Firebase-Key nötig.

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.

Gemini hat das greifbar gemacht. Im Februar 2026 berichtete Truffle Security: Wurde in einem Google-Cloud-Projekt die Gemini-API aktiviert, konnten die unbeschränkten Keys dieses Projekts, auch solche, die längst für Maps oder Firebase veröffentlicht waren, Gemini aufrufen, auf hochgeladene Dateien zugreifen und Kosten verursachen. Laut Gemini-Dokumentation lehnt die API unbeschränkte Standard-Keys inzwischen ab, und Firebase warnt davor, die Gemini Developer API jemals in die Liste erlaubter APIs eines öffentlich zugänglichen Keys aufzunehmen. Beschränke jeden öffentlichen Key auf die APIs, die er tatsächlich nutzt, und rufe Gemini über deinen Server oder über Firebase AI Logic mit App Check auf.

• Firebase: API-Keys kennenlernen und verwalten ↗
• Truffle Security: Google-API-Keys und Gemini ↗
• Google AI: Gemini-API-Keys verwenden ↗
• Firebase AI Logic ↗

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.

Wenn das Backend mit Firmensystemen verbunden ist, hilft zusätzlich der Leitfaden zur Netzwerksegmentierung und Begrenzung von Gerätezugriffen.

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 der Anfragen veränderter Apps. Die Prüfung ist jedoch nicht unfehlbar: Geräte können die Technik nicht unterstützen oder kompromittiert sein, der Attestierungsdienst kann ausfallen und ein Angreifer kann eine echte App bedienen. Aktiviere die verpflichtende Prüfung schrittweise und beobachte die Auswirkungen. Lege das Verhalten bei Ausfällen fest und behalte Authentifizierung, Autorisierung, Ratenbegrenzung und Protokollierung bei.

Priorisiere Aktionen mit erhöhtem Risiko oder Kosten: etwa das Einlösen eines Angebots, teure KI-Anfragen, bezahlte Inhalte oder Änderungen an einem Zahlungskonto. Für einen öffentlichen Katalog können andere Anforderungen gelten.

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.

Verlagere den privilegierten Aufruf auf einen Server oder eine verwaltete Funktion. Prüfe dort die Rechte des Nutzers und gib dem Dienst nur die nötigen Berechtigungen. Das Geheimnis in einer neuen App-Version lediglich stärker zu verschleiern, behebt das Architekturproblem nicht.

Wie leistungsfähigere Modelle diese Arbeit verändern, erklärt KI-Hacking-Agenten: belegte Fortschritte und Grenzen.