Est-il sûr de rendre votre clé API Firebase publique ?

Oui. 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). Votre configuration web, google-services.json et GoogleService-Info.plist contiennent la clé, et chaque utilisateur de votre app en a une copie.

Mais publique ne veut pas dire inoffensive. La clé est sûre quand deux conditions sont réunies : elle ne peut appeler que les API dont votre app a besoin, et vos données sont protégées par les Security Rules et App Check. Qu'une seule manque, et la clé devient la porte d'entrée vers votre facture.

La plupart des clés API fonctionnent comme des mots de passe. Pas celles de Firebase : elles indiquent à quel projet une requête est destinée, pour que Google applique quotas et facturation. Firebase explique qu'elles sont "API keys for Firebase services are not used to control access to backend resources" (les clés API des services Firebase ne servent pas à contrôler l'accès aux ressources du backend). Selon ses propres mots : "None of the Firebase-related APIs use an API key as authorization for calling the API." (aucune des API liées à Firebase n'utilise une clé API comme autorisation pour appeler l'API).

Qui peut lire ou écrire quoi, ce sont les Security Rules de Firebase qui le décident, et quelles apps peuvent appeler votre backend, App Check. C'est pourquoi cacher la clé ne sert à rien, et pourquoi Firebase prévient : "Don't rely only on restricting and/or obscuring your API keys." (ne comptez pas seulement sur la restriction ou la dissimulation de vos clés API). Tout ce qui se trouve dans votre frontend, variables d'environnement comprises, finit dans le code que vos utilisateurs téléchargent.

• Lire ou modifier vos données. Pas si vos Security Rules vérifient qui fait la demande. La clé ne passe pas outre les règles.
• Se connecter à la place d'un de vos utilisateurs. Pas sans les identifiants de cet utilisateur.
• Appeler des API que la clé n'a pas le droit d'appeler. Avec des restrictions d'API, toute autre API la refuse.

• Appeler toute API que la clé autorise, à vos frais. Une clé sans restriction fonctionne avec toutes les API activées dans le projet. Si Gemini, Maps ou une autre API payante est activée, un inconnu peut l'utiliser et c'est vous qui payez. C'est ainsi qu'est arrivée une facture Gemini de 82 314 $.
• Marteler vos points de connexion. Firebase signale qu'une personne disposant de votre clé pourrait "use your API key to access Firebase's authentication endpoints and make authentication requests against your project." (utiliser votre clé API pour accéder aux points de terminaison d'authentification de Firebase et envoyer des requêtes d'authentification à votre projet). Par exemple, pour tester des mots de passe. Il conseille d'abaisser le quota de l'API Identity Toolkit à votre trafic normal.
• Utiliser votre backend depuis son propre code. Avec votre configuration, un script peut lire et écrire tout ce que vos règles autorisent, et faire grimper les lectures et écritures au passage. C'est App Check qui distingue votre app de ce script.

• Restreignez ses API. N'autorisez que les API que votre app appelle. Étape par étape : comment restreindre une clé API Firebase.
• Ne mettez jamais côté client une clé qui n'est pas Firebase. Une clé de la Gemini Developer API, une clé serveur Maps ou un fichier de compte de service sont de vrais secrets. Firebase dit que la clé Gemini "should never be included in your code or configuration files." (ne doit jamais figurer dans votre code ni dans vos fichiers de configuration).
• Fermez vos Security Rules. Pas de allow read, write: if true en dehors d'un projet de test.
• Activez App Check. C'est l'outil de Firebase pour "preventing unauthorized clients from accessing your backend resources" (empêcher les clients non autorisés d'accéder aux ressources de votre backend), même si Firebase reconnaît qu'il "prevents some, but not all, abuse vectors" (bloque certains vecteurs d'abus, mais pas tous).
• Plafonnez le volume. Un quota journalier sur les API payantes et un budget qui déclenche une action, pas seulement un email, bornent ce que peut coûter une faille oubliée (comment limiter les dépenses Firebase).