Comment restreindre une clé API Firebase, étape par étape

Une clé API Firebase se trouve dans la configuration de votre app : quiconque ouvre votre site ou décompresse votre app peut la copier. C'est prévu : Firebase écrit "API keys for Firebase services are OK to include in code or checked-in config files." (les clés API des services Firebase peuvent figurer dans le code ou dans des fichiers de configuration versionnés) (Clés API Firebase). Ce qui pose problème, c'est une clé qui peut appeler plus que ce dont votre app a besoin. La documentation de Google est sans détour : "Unrestricted API keys are insecure." (les clés API sans restriction ne sont pas sûres) (restrictions des clés API).

Trois de nos histoires de factures cauchemar ont commencé de la même façon, avec une clé publique qui pouvait aussi appeler Gemini : 82 314 $ en 48 heures, 54 000 € en 13 heures et 67 000 $ en 19 heures.

Firebase restreint les clés qu'il crée, mais une clé ancienne peut autoriser plus que vous ne le pensez. Quand Firebase a restreint les clés existantes en mai 2024, chacune a été "restricted to the list of the Firebase-related APIs plus any of the project's currently enabled APIs." (limitée à la liste des API liées à Firebase plus toutes les API alors activées dans le projet). Une API payante activée à ce moment-là est restée sur la clé.

Ouvrez API et services > Identifiants dans la console Google Cloud et choisissez votre projet : toutes les clés API y figurent. Firebase en crée une par plateforme, une Browser key avec le projet et une clé iOS ou Android quand vous ajoutez ces apps. Cherchez aussi les clés créées à la main par vous ou un collègue, et celles arrivées avec d'autres services Google, comme Maps.

Pour savoir quelle clé utilise chaque app, allez dans la console Firebase, Paramètres du projet > Général > Vos applications. Les apps web l'affichent comme apiKey dans l'objet de configuration, les apps Android comme current_key dans google-services.json, et les apps Apple comme API_KEY dans GoogleService-Info.plist.

C'est la restriction qui borne les dégâts. Sans elle, "an API key can be used to access any API that is enabled for the project." (une clé API peut servir à accéder à n'importe quelle API activée dans le projet) (Clés API Firebase).

Dans la page Identifiants :

1. Cliquez sur le nom de la clé.
2. Sous Restrictions relatives aux API, choisissez Restreindre la clé.
3. Sélectionnez seulement les API que votre app appelle depuis le client. Pour une app Firebase classique, ce sont les API Firebase qu'elle utilise, comme Identity Toolkit pour Auth, Cloud Firestore et Firebase Installations.
4. Cliquez sur Enregistrer.

Prudence avec les clés de production. Si vous retirez une API dont votre app a besoin, ses appels échouent avec une erreur API_KEY_SERVICE_BLOCKED. Firebase tient une liste des API nécessaires à chaque service Firebase : consultez-la avant d'en retirer une, et testez d'abord le changement sur une clé de test.

En ligne de commande, listez les clés pour obtenir leurs ID, puis définissez les API. La liste que vous passez est la liste complète : "the service names provided replace any existing services on the key." (les noms de service fournis remplacent ceux déjà présents sur la clé)

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

Les restrictions d'application indiquent quels sites ou quelles apps peuvent utiliser la clé. Sans elles, comme le dit Google, "API keys without application restrictions can be used from anywhere." (les clés API sans restriction d'application peuvent être utilisées depuis n'importe où). Chaque clé n'accepte qu'un type : "You can apply only one application restriction type at a time." (vous ne pouvez appliquer qu'un seul type de restriction d'application à la fois). Choisissez celui qui correspond à la clé (restrictions des clés API) :

• Sites web. Pour la Browser key, ajoutez vos domaines comme référents HTTP. Pour autoriser un site entier, la documentation de Google utilise deux entrées, example.com/* et *.example.com/*. Utilisez une clé à part pour localhost plutôt que de l'ajouter à la clé de production.
• Apps Android. Ajoutez le nom du package et l'empreinte SHA-1 de chaque certificat de signature.
• Apps iOS. Ajoutez le bundle ID.

Voyez-les comme un filtre, pas comme un verrou. Pour les restrictions Android et iOS, Google prévient : "Bypassing this restriction is straightforward." (contourner cette restriction est simple). Un référent n'est lui aussi qu'un en-tête, et un script hors navigateur peut envoyer la valeur qu'il veut. Les restrictions d'application empêchent la réutilisation occasionnelle de votre clé. Ce sont les restrictions d'API de l'étape 2 qui limitent la facture.

Le conseil de Firebase est direct : "never include the Gemini Developer API in the allowlist for a publicly accessible API key or a key used for other services." (n'incluez jamais la Gemini Developer API dans la liste d'une clé API publique ou d'une clé utilisée pour d'autres services) (Clés API Firebase). Il en va de même pour toute API Google Cloud facturée, comme Maps, Vision ou Translation. Donnez-lui une clé à part qui ne peut appeler que cette API, pour pouvoir la restreindre, la renouveler ou la supprimer sans toucher à Firebase.

Si votre serveur appelle la Gemini Developer API, cette clé est un vrai secret. Firebase précise qu'elle "should never be included in your code or configuration files." (ne doit jamais figurer dans votre code ni dans vos fichiers de configuration). Gardez-la dans les secrets de votre backend, jamais dans l'app.

Si votre app appelle Gemini via Firebase AI Logic, les requêtes passent par Firebase et il n'y a aucune clé Gemini côté client. Toute personne disposant de la configuration de votre app peut tout de même essayer de les envoyer : protégez-les avec App Check et un quota journalier sur l'API (comment fixer des limites).

Une clé qui n'aurait jamais dû être publique, comme une clé serveur poussée dans un dépôt, demande plus que des restrictions. Renouvelez-la : sur la page de la clé, cliquez sur Effectuer la rotation de la clé. Google crée une nouvelle clé avec les mêmes restrictions, vous y basculez vos apps et vos serveurs, puis vous supprimez l'ancienne (rotation d'une clé API).

Une clé Firebase dans une app publiée, c'est autre chose. Chaque copie installée la contient, donc la renouveler casse les anciennes versions. Pour cette clé, la solution, ce sont les restrictions ci-dessus.

Une clé restreinte peut toujours appeler toutes les API de sa liste, aussi souvent qu'on le souhaite. Trois autres couches s'en chargent : les Security Rules décident qui lit et écrit quelles données, App Check rejette les requêtes qui ne viennent pas de votre vraie app, et les quotas plafonnent le nombre d'appels qu'une API accepte par jour. Comment limiter les dépenses Firebase les détaille une par une.

Et si quelque chose passe malgré tout, FireShield surveille l'usage de chaque API toutes les quelques minutes. Un service sans trafic qui reçoit soudain des milliers de requêtes, comme Gemini dans les trois histoires ci-dessus, est repéré en quelques minutes et peut déclencher une action, jusqu'à dissocier la facturation.