Bei Firebase gibt es keine Service Roles wie bei Supabase, aber es gibt ein Gegenstück: den Dienstkonto-Schlüssel des Admin SDK. Der wird gefährlich öffentlich, wenn eine Low-Code- oder KI-generierte App ihn in den Client oder in ein öffentliches Repository legt. Die normale Firebase-Web-Konfiguration mit dem API-Schlüssel ist dagegen absichtlich öffentlich und harmlos, weil sie nur das Projekt benennt und keinen Zugriff gewährt. Kurz gesagt: Der öffentliche Web-Schlüssel ist sicher, der private Dienstkonto-Schlüssel niemals. Wer beides verwechselt, riskiert vollen Admin-Zugriff auf das Backend.
Kurze Antwort
Firebase-Zugangsdaten sind in zwei Klassen aufgeteilt. Die Web-Konfiguration mit dem API-Schlüssel ist laut Firebase kein Geheimnis und darf im Client-Code stehen, weil sie nur das Projekt identifiziert. Der Dienstkonto-Schlüssel des Admin SDK dagegen gewährt vollen, privilegierten Zugriff und gehört ausschließlich auf den Server. Öffentlich im schädlichen Sinne wird nur dieser Dienstkonto-Schlüssel, und zwar durch einen Fehler wie das Einbetten in die App oder das Committen in ein Repository. Ist das passiert, muss er sofort rotiert werden.
Was "Service Roles" bei Firebase bedeuten
Der Begriff Service Role stammt eigentlich von Supabase, wo der service_role-Schlüssel die Zeilensicherheit umgeht und vollen Zugriff hat. Viele Low-Code-Entwickler übertragen den Begriff auf Firebase, meinen damit aber das Firebase-Pendant: die Anmeldedaten des Admin SDK, also einen Dienstkonto-Schlüssel. Dieser Schlüssel ist eine JSON-Datei mit einem privaten Schlüssel und dient dazu, dass ein Server im Namen des Projekts uneingeschränkt handeln kann.
Wichtig ist die saubere Trennung von der Web-Konfiguration. Wenn eine Firebase-App im Browser oder auf dem Handy startet, lädt sie eine Konfiguration mit API-Schlüssel, Projekt-ID und ähnlichen Werten. Diese Werte sind Kennungen, keine Passwörter, und Firebase schützt die Daten nicht dadurch, dass diese Werte geheim wären, sondern über Firebase Authentication und Security Rules. Das privilegierte Gegenstück, der Dienstkonto-Schlüssel, arbeitet auf einer ganz anderen Ebene und übergeht diese Schutzmechanismen vollständig.
Wann Firebase-Zugangsdaten öffentlich sind
Die Web-Konfiguration ist praktisch immer öffentlich, weil sie mit dem Client ausgeliefert wird, und das ist so vorgesehen und unbedenklich. Sie im Netzwerkverkehr oder im App-Paket zu sehen, ist kein Sicherheitsvorfall. Der Dienstkonto-Schlüssel dagegen soll nie öffentlich sein und wird es nur durch einen Fehler: wenn er versehentlich in ein öffentliches GitHub-Repository gelangt, in das App-Bundle eingebettet oder über einen falsch konfigurierten Endpunkt zugänglich wird.
Genau das passiert in Low-Code- und Vibe-Code-Projekten überdurchschnittlich oft. Der Grund ist, dass generierte oder zusammengeklickte Backends die Grenze zwischen Client und Server verwischen. Ein KI-Assistent fügt zum Beispiel Servercode mit dem Dienstkonto-Schlüssel in dasselbe Projekt ein, das später als Client veröffentlicht wird, oder eine Anleitung legt die Schlüsseldatei ins Repository. Die Web-Konfiguration darf dort liegen, der Dienstkonto-Schlüssel nicht, und die Verwechslung dieser beiden ist die eigentliche Vibe-Code-Gefahr.
Was ein Angreifer damit tun kann
Ein geleakter Dienstkonto-Schlüssel ist ein vollständiger Kompromiss des Backends, nicht ein kleines Leck. Mit ihm kann ein Angreifer als Administrator des Projekts auftreten: alle Daten in der Datenbank lesen, ändern und löschen, beliebige Nutzer anlegen, sperren oder deren Sitzungen fälschen und generell jede Operation ausführen, die sonst nur vertrauenswürdigem Servercode vorbehalten ist. Es gibt dabei keine Einschränkung auf einen einzelnen Nutzer oder einen Teilbereich.
Der entscheidende Punkt ist, dass dieser Zugriff die üblichen Schutzmechanismen ignoriert. Der Admin-Zugriff prüft keine Security Rules und keinen angemeldeten Nutzer, weil er per Definition über diesen Kontrollen steht. Deshalb ist ein exponierter Dienstkonto-Schlüssel weit schwerwiegender als ein exponierter öffentlicher Web-Schlüssel: Letzterer gibt nur den Weg frei, den die Regeln ohnehin absichern, Ersterer hebelt die Absicherung komplett aus. Ein solcher Fund gehört in die höchste Dringlichkeitsstufe.
Ändern die Security Rules das Risiko?
Security Rules sind das zentrale Schutzsystem für den Client-Pfad, also für alles, was über die öffentliche Web-Konfiguration läuft. Gut geschriebene Regeln, die standardmäßig verweigern und Zugriff nur dem passenden angemeldeten Nutzer gewähren, sorgen dafür, dass der öffentliche API-Schlüssel harmlos bleibt. Für diesen Pfad senken die Regeln das Risiko also erheblich und sind der Grund, warum die Web-Konfiguration überhaupt öffentlich sein darf.
Gegen einen geleakten Dienstkonto-Schlüssel helfen sie jedoch nicht. Da der Admin-Zugriff die Regeln absichtlich umgeht, bleibt die Datenbank auch bei perfekten Security Rules vollständig offen, sobald der private Schlüssel in falsche Hände gerät. Die Regeln und der Dienstkonto-Schlüssel liegen auf verschiedenen Ebenen: Die Regeln schützen den öffentlichen Weg, der Dienstkonto-Schlüssel geht daran vorbei. Man darf sich deshalb nie darauf verlassen, dass gute Regeln einen ausgelaufenen Admin-Schlüssel auffangen, denn das tun sie nicht.
Sofortmaßnahmen: rotieren und absichern
Wenn ein Dienstkonto-Schlüssel exponiert wurde, ist die erste und dringendste Maßnahme, ihn zu rotieren. Widerrufen Sie den geleakten Schlüssel in der Google-Cloud- beziehungsweise Firebase-Konsole und erzeugen Sie einen neuen, sodass der alte sofort ungültig wird. Prüfen Sie anschließend die Protokolle auf ungewöhnliche Zugriffe, denn zwischen Leak und Rotation kann Missbrauch stattgefunden haben, und behandeln Sie die Daten entsprechend.
Danach folgt die Architekturkorrektur, damit es nicht erneut passiert. Der Dienstkonto-Schlüssel gehört ausschließlich auf einen Server oder in eine sichere Umgebung, niemals in das App-Bundle oder in ein Repository. Entfernen Sie ihn aus der Versionskontrolle vollständig, nicht nur aus dem letzten Commit, und nutzen Sie eine Geheimnisverwaltung oder Umgebungsvariablen auf dem Server. Der Client soll nur die öffentliche Web-Konfiguration zusammen mit Firebase Authentication und Security Rules verwenden. So bleibt der privilegierte Zugriff dort, wo er hingehört.
Öffentlich gegen geheim
Die beiden Klassen von Zugangsdaten nebeneinander zu sehen, macht die Regel eindeutig. Die Tabelle fasst zusammen.
| Merkmal | Web-Konfiguration (API-Schlüssel) | Dienstkonto-Schlüssel (Admin SDK) |
|---|---|---|
| Zweck | Projekt identifizieren | Voller Admin-Zugriff |
| Öffentlich sichtbar | Vorgesehen und sicher | Niemals, nur durch Fehler |
| Ort | Client-App | Nur Server |
| Security Rules | Schützen diesen Pfad | Werden umgangen |
| Leak-Schwere | Kein Vorfall | Kritischer Vorfall |
Lesen Sie die letzte Zeile als Kern: Nur der Dienstkonto-Schlüssel macht aus einem Fund einen echten Notfall.
Prüfliste
Vor der Veröffentlichung einer Low-Code-App lohnt sich dieser kurze Durchgang. Die Liste deckt das Wichtigste ab.
| Prüfung | Maßnahme | Erledigt? |
|---|---|---|
| Kein Dienstkonto im Client | App-Bundle auf JSON-Schlüssel prüfen | [ ] |
| Repository sauber | Keine Schlüsseldatei in der Versionskontrolle | [ ] |
| Web-Konfiguration verstanden | API-Schlüssel als öffentlich akzeptieren | [ ] |
| Security Rules aktiv | Standardmäßig verweigern, pro Nutzer freigeben | [ ] |
| Geleakten Schlüssel rotiert | Alten widerrufen, neuen serverseitig ablegen | [ ] |
| Serverseitige Ablage | Geheimnisverwaltung statt Client nutzen | [ ] |
Am häufigsten übersehen wird die erste Prüfung: Ein im App-Bundle vergessener Dienstkonto-Schlüssel ist der Fehler, der ein sicheres System öffnet.
Wo die Sicherheitsanalyse hilft
Die Trennung von öffentlichem und geheimem Schlüssel zu verstehen, ist Wissen; zu bestätigen, dass die App diese Trennung einhält, ist eine Prüfung, und dabei hilft eine Analyse.
Ein Scanner wie PTKD.com analysiert das Paket Ihrer Android- oder iOS-App und meldet, wenn ein Geheimnis, das auf den Server gehört, etwa ein Dienstkonto-Schlüssel oder ein anderer privilegierter Zugangsdaten-Satz, im Client eingebettet wurde, zugeordnet zu OWASP MASVS. Zur Klarheit über die Grenze: Einen öffentlichen Firebase-Web-Schlüssel in der App zu finden, ist kein Problem und wird nicht als solches behandelt. Der Scanner sucht das Gegenteil, nämlich das echte Geheimnis, das auf die öffentliche Seite gelangt ist, und deshalb ist eine Analyse vor der Veröffentlichung der richtige Moment, um zu bestätigen, dass nur der öffentliche Schlüssel mitgereist ist.
Das Wichtigste
- Firebase hat keine Service Roles wie Supabase, aber das Gegenstück ist der Dienstkonto-Schlüssel des Admin SDK, der vollen privilegierten Zugriff gewährt.
- Die Web-Konfiguration mit API-Schlüssel ist absichtlich öffentlich und sicher, weil sie nur das Projekt identifiziert; der Dienstkonto-Schlüssel darf niemals öffentlich sein.
- In Low-Code- und Vibe-Code-Apps wird der Dienstkonto-Schlüssel durch Fehler exponiert, etwa durch Einbetten in die App oder Committen in ein Repository.
- Security Rules schützen den Client-Pfad und machen den öffentlichen Schlüssel harmlos, aber ein Dienstkonto-Schlüssel umgeht sie vollständig, weshalb ein Leak sofortige Rotation erfordert.
- Prüfen Sie vor der Veröffentlichung, dass kein privilegierter Schlüssel im Client liegt, und nutzen Sie ein Werkzeug wie PTKD.com, um genau das zu bestätigen.
