So schränken Sie einen Firebase-API-Schlüssel ein, Schritt für Schritt

Ein Firebase-API-Schlüssel steht in der Konfiguration Ihrer App, also kann ihn jeder kopieren, der Ihre Website öffnet oder Ihre App entpackt. Das ist so vorgesehen: Firebase schreibt "API keys for Firebase services are OK to include in code or checked-in config files." (API-Schlüssel für Firebase-Dienste dürfen im Code oder in eingecheckten Konfigurationsdateien stehen) (Firebase-API-Schlüssel). Problematisch ist ein Schlüssel, der mehr aufrufen kann, als Ihre App braucht. Die Google-Dokumentation sagt es deutlich: "Unrestricted API keys are insecure." (uneingeschränkte API-Schlüssel sind unsicher) (Einschränkungen für API-Schlüssel).

Drei unserer Rechnungs-Horrorgeschichten begannen gleich, mit einem öffentlichen Schlüssel, der auch Gemini aufrufen konnte: 82.314 $ in 48 Stunden, 54.000 € in 13 Stunden und 67.000 $ in 19 Stunden.

Firebase schränkt die Schlüssel ein, die es selbst erstellt, aber ein älterer Schlüssel erlaubt vielleicht mehr, als Sie denken. Als Firebase im Mai 2024 bestehende Schlüssel einschränkte, wurde jeder "restricted to the list of the Firebase-related APIs plus any of the project's currently enabled APIs." (auf die Liste der Firebase-bezogenen APIs plus aller damals im Projekt aktivierten APIs beschränkt). Eine kostenpflichtige API, die damals aktiviert war, blieb auf dem Schlüssel.

Öffnen Sie APIs & Dienste > Anmeldedaten in der Google Cloud Console und wählen Sie Ihr Projekt: Dort stehen alle API-Schlüssel. Firebase erstellt einen pro Plattform, einen Browser key mit dem Projekt und einen iOS- oder Android-Schlüssel, wenn Sie diese Apps hinzufügen. Suchen Sie auch nach Schlüsseln, die Sie oder Kollegen von Hand angelegt haben, und nach solchen, die mit anderen Google-Diensten wie Maps kamen.

Welchen Schlüssel jede App verwendet, sehen Sie in der Firebase Console unter Projekteinstellungen > Allgemein > Meine Apps. Web-Apps zeigen ihn als apiKey im Konfigurationsobjekt, Android-Apps als current_key in google-services.json und Apple-Apps als API_KEY in GoogleService-Info.plist.

Diese Einschränkung begrenzt den Schaden. Ohne sie gilt: "an API key can be used to access any API that is enabled for the project." (ein API-Schlüssel kann für jede im Projekt aktivierte API verwendet werden) (Firebase-API-Schlüssel).

Auf der Seite Anmeldedaten:

1. Klicken Sie auf den Namen des Schlüssels.
2. Wählen Sie unter API-Einschränkungen die Option Schlüssel einschränken.
3. Wählen Sie nur die APIs aus, die Ihre App vom Client aufruft. Bei einer typischen Firebase-App sind das die Firebase-APIs, die sie nutzt, etwa Identity Toolkit für Auth, Cloud Firestore und Firebase Installations.
4. Klicken Sie auf Speichern.

Vorsicht bei Produktionsschlüsseln. Entfernen Sie eine API, die Ihre App braucht, schlagen ihre Aufrufe mit dem Fehler API_KEY_SERVICE_BLOCKED fehl. Firebase führt eine Liste der APIs, die jeder Firebase-Dienst braucht: Prüfen Sie sie, bevor Sie eine entfernen, und testen Sie die Änderung zuerst an einem Testschlüssel.

Über die Kommandozeile listen Sie die Schlüssel auf, um ihre IDs zu bekommen, und setzen dann die APIs. Die übergebene Liste ist die vollständige Liste: "the service names provided replace any existing services on the key." (die angegebenen Dienstnamen ersetzen alle bisherigen Dienste des Schlüssels)

gcloud services api-keys list --project=PROJECT_ID

gcloud services api-keys update KEY_ID \
  --api-target=service=identitytoolkit.googleapis.com \
  --api-target=service=securetoken.googleapis.com \
  --api-target=service=firestore.googleapis.com \
  --api-target=service=firebaseinstallations.googleapis.com

Anwendungseinschränkungen legen fest, welche Websites oder Apps den Schlüssel verwenden dürfen. Ohne sie gilt, wie Google schreibt: "API keys without application restrictions can be used from anywhere." (API-Schlüssel ohne Anwendungseinschränkungen können von überall verwendet werden). Jeder Schlüssel erlaubt nur eine Art: "You can apply only one application restriction type at a time." (Sie können jeweils nur einen Typ von Anwendungseinschränkung anwenden). Wählen Sie den passenden (Einschränkungen für API-Schlüssel):

• Websites. Tragen Sie beim Browser key Ihre Domains als HTTP-Referrer ein. Um eine ganze Website zu erlauben, nutzt die Google-Dokumentation zwei Einträge, example.com/* und *.example.com/*. Verwenden Sie für localhost einen eigenen Schlüssel, statt ihn beim Produktionsschlüssel einzutragen.
• Android-Apps. Tragen Sie den Paketnamen und den SHA-1-Fingerabdruck jedes Signaturzertifikats ein.
• iOS-Apps. Tragen Sie die Bundle-ID ein.

Sehen Sie das als Filter, nicht als Schloss. Zu den Android- und iOS-Einschränkungen warnt Google: "Bypassing this restriction is straightforward." (diese Einschränkung zu umgehen ist einfach). Auch ein Referrer ist nur ein Header, und ein Skript außerhalb des Browsers kann jeden beliebigen Wert senden. Anwendungseinschränkungen verhindern die beiläufige Wiederverwendung Ihres Schlüssels. Die Rechnung begrenzen die API-Einschränkungen aus Schritt 2.

Der Rat von Firebase ist eindeutig: "never include the Gemini Developer API in the allowlist for a publicly accessible API key or a key used for other services." (nehmen Sie die Gemini Developer API nie in die Liste eines öffentlich zugänglichen API-Schlüssels oder eines für andere Dienste genutzten Schlüssels auf) (Firebase-API-Schlüssel). Dasselbe gilt für jede kostenpflichtige Google-Cloud-API wie Maps, Vision oder Translation. Geben Sie ihr einen eigenen Schlüssel, der nur diese API aufrufen kann, damit Sie ihn einschränken, rotieren oder löschen können, ohne Firebase anzufassen.

Ruft Ihr Server die Gemini Developer API auf, ist dieser Schlüssel ein echtes Geheimnis. Firebase schreibt, dass er "should never be included in your code or configuration files." (nie in Ihrem Code oder Ihren Konfigurationsdateien stehen sollte). Bewahren Sie ihn in den Secrets Ihres Backends auf, nie in der App.

Ruft Ihre App Gemini über Firebase AI Logic auf, laufen die Anfragen über Firebase, und im Client steckt kein Gemini-Schlüssel. Jeder mit der Konfiguration Ihrer App kann trotzdem versuchen, sie zu senden. Schützen Sie sie deshalb mit App Check und einem Tageskontingent für die API (wie Sie Limits setzen).

Ein Schlüssel, der nie öffentlich sein sollte, etwa ein Serverschlüssel in einem Repository, braucht mehr als Einschränkungen. Rotieren Sie ihn: Klicken Sie auf der Seite des Schlüssels auf Schlüssel rotieren. Google erstellt einen neuen Schlüssel mit denselben Einschränkungen, Sie stellen Ihre Apps und Server darauf um und löschen dann den alten (API-Schlüssel rotieren).

Ein Firebase-Schlüssel in einer veröffentlichten App ist etwas anderes. Jede installierte Kopie enthält ihn, eine Rotation macht also alte Versionen kaputt. Für diesen Schlüssel sind die Einschränkungen oben die Lösung.

Ein eingeschränkter Schlüssel kann weiterhin jede API auf seiner Liste aufrufen, so oft jemand will. Dafür gibt es drei weitere Ebenen: Security Rules entscheiden, wer welche Daten liest und schreibt, App Check lehnt Anfragen ab, die nicht von Ihrer echten App kommen, und Kontingente begrenzen, wie viele Aufrufe eine API pro Tag annimmt. So begrenzen Sie Firebase-Kosten erklärt jede davon.

Und wenn doch etwas durchkommt, überwacht FireShield die Nutzung jeder API alle paar Minuten. Ein Dienst ohne Traffic, der plötzlich Tausende Anfragen bekommt, wie Gemini in den drei Geschichten oben, wird innerhalb von Minuten erkannt und kann eine Aktion auslösen, bis hin zum Trennen der Abrechnung.