Ist es sicher, Ihren Firebase-API-Schlüssel öffentlich zu machen?

Ja. 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). Ihre Web-Konfiguration, google-services.json und GoogleService-Info.plist enthalten den Schlüssel, und jeder Nutzer Ihrer App hat eine Kopie.

Aber öffentlich heißt nicht harmlos. Der Schlüssel ist sicher, wenn zwei Dinge stimmen: Er kann nur die APIs aufrufen, die Ihre App braucht, und Ihre Daten sind durch Security Rules und App Check geschützt. Fehlt eines davon, wird der Schlüssel zum Tor zu Ihrer Rechnung.

Die meisten API-Schlüssel funktionieren wie Passwörter. Firebase-Schlüssel nicht: Sie sagen, zu welchem Projekt eine Anfrage gehört, damit Google Kontingente und Abrechnung anwenden kann. Firebase erklärt, dass sie "API keys for Firebase services are not used to control access to backend resources" (API-Schlüssel für Firebase-Dienste werden nicht verwendet, um den Zugriff auf Backend-Ressourcen zu steuern). In eigenen Worten: "None of the Firebase-related APIs use an API key as authorization for calling the API." (keine der Firebase-bezogenen APIs verwendet einen API-Schlüssel als Autorisierung für den API-Aufruf).

Wer was lesen oder schreiben darf, entscheiden die Firebase Security Rules, und welche Apps Ihr Backend aufrufen dürfen, entscheidet App Check. Deshalb bringt es nichts, den Schlüssel zu verstecken, und deshalb warnt Firebase: "Don't rely only on restricting and/or obscuring your API keys." (verlassen Sie sich nicht nur darauf, Ihre API-Schlüssel einzuschränken oder zu verbergen). Alles in Ihrem Frontend, Umgebungsvariablen eingeschlossen, landet in dem Code, den Ihre Nutzer herunterladen.

• Ihre Daten lesen oder ändern. Nicht, wenn Ihre Security Rules prüfen, wer fragt. Der Schlüssel kommt an den Regeln nicht vorbei.
• Sich als einer Ihrer Nutzer anmelden. Nicht ohne die Zugangsdaten dieses Nutzers.
• APIs aufrufen, die der Schlüssel nicht aufrufen darf. Mit API-Einschränkungen lehnt jede andere API ihn ab.

• Jede API aufrufen, die der Schlüssel erlaubt, auf Ihre Rechnung. Ein uneingeschränkter Schlüssel funktioniert mit jeder im Projekt aktivierten API. Ist Gemini, Maps oder eine andere kostenpflichtige API aktiviert, kann ein Fremder sie nutzen, und Sie zahlen. So entstand eine Gemini-Rechnung über 82.314 $.
• Ihre Anmelde-Endpunkte bombardieren. Firebase weist darauf hin, dass jemand mit Ihrem Schlüssel "use your API key to access Firebase's authentication endpoints and make authentication requests against your project." (Ihren API-Schlüssel nutzen könnte, um auf die Authentifizierungs-Endpunkte von Firebase zuzugreifen und Authentifizierungsanfragen gegen Ihr Projekt zu stellen). Zum Beispiel, um Passwörter auszuprobieren. Firebase empfiehlt, das Kontingent der Identity Toolkit API an Ihren normalen Traffic anzupassen.
• Ihr Backend aus eigenem Code nutzen. Mit Ihrer Konfiguration kann ein Skript alles lesen und schreiben, was Ihre Regeln erlauben, und dabei Lese- und Schreibvorgänge in die Höhe treiben. App Check unterscheidet Ihre App von diesem Skript.

• Seine APIs einschränken. Erlauben Sie nur die APIs, die Ihre App aufruft. Schritt für Schritt: So schränken Sie einen Firebase-API-Schlüssel ein.
• Nie einen Nicht-Firebase-Schlüssel in den Client. Ein Schlüssel für die Gemini Developer API, ein Maps-Serverschlüssel oder eine Dienstkontodatei sind echte Geheimnisse. Firebase schreibt, dass der Gemini-Schlüssel "should never be included in your code or configuration files." (nie in Ihrem Code oder Ihren Konfigurationsdateien stehen sollte).
• Ihre Security Rules schließen. Kein allow read, write: if true außerhalb eines Testprojekts.
• App Check aktivieren. Es ist das Werkzeug von Firebase zum "preventing unauthorized clients from accessing your backend resources" (Verhindern, dass nicht autorisierte Clients auf Ihre Backend-Ressourcen zugreifen), auch wenn Firebase einräumt, dass es "prevents some, but not all, abuse vectors" (einige, aber nicht alle Missbrauchswege verhindert).
• Das Volumen deckeln. Ein Tageskontingent für kostenpflichtige APIs und ein Budget, das eine Aktion auslöst und nicht nur eine E-Mail, begrenzen, was eine übersehene Lücke kosten kann (So begrenzen Sie Firebase-Kosten).