Pour sécuriser vos ressources Firebase et les données de vos utilisateurs, suivez ces consignes. Tous les éléments ne s'appliqueront pas nécessairement à vos besoins, mais gardez-les à l'esprit lorsque vous développerez votre application.
Éviter le trafic abusif
Configurer la surveillance et les alertes pour les services de backend
Pour détecter le trafic abusif, tel que les attaques par déni de service (DoS), configurez la surveillance et les alertes pour Cloud Firestore, Realtime Database, Cloud Storage, et Hosting
Si vous soupçonnez une attaque sur votre application, contactez l'assistance dès que possible pour l'informer de ce qui se passe.
Activer App Check
Pour vous assurer que seules vos applications peuvent accéder à vos services de backend, activez Firebase App Check pour chaque service compatible.
Configurez vos Cloud Functions pour qu'elles soient adaptées au trafic normal
Cloud Functions s'adapte automatiquement aux besoins de votre application, mais en cas d'attaque, cela peut entraîner une facture élevée. Pour éviter cela, vous pouvez limiter le nombre d'instances simultanées d'une fonction en fonction du trafic normal de votre application.
Configurer des alertes pour être averti lorsque les limites sont presque atteintes
Si votre service connaît des pics de requêtes, les quotas sont souvent appliqués et le trafic vers votre application est automatiquement limité.
Assurez-vous de surveiller votre tableau de bordUtilisation et facturation.
Configurez des alertes budgétaires pour votre projet afin d'être averti lorsque l'utilisation des ressources dépasse les prévisions.
Si vous utilisez Firebase AI Logic, Firebase App Hosting, Cloud Functions for Firebase, et Firebase Extensions, définissez des limites de dépenses pour suspendre le service applicable si votre projet atteint le budget défini pour ce service.
Éviter les auto-DoS : tester les fonctions localement avec les émulateurs
Il est facile de s'auto-DoS accidentellement lors du développement Cloud Functions, par exemple en créant une boucle de déclenchement-écriture infinie. Vous pouvez éviter que ces erreurs n'affectent les services en direct en effectuant votre développement avec le Firebase Local Emulator Suite.
Si vous vous auto-DoS accidentellement, annulez le déploiement de votre fonction en la supprimant de index.js et en exécutant
firebase deploy --only functions
Lorsque la réactivité en temps réel est moins importante, structurez les fonctions de manière défensive
Si vous n'avez pas besoin de présenter le résultat d'une fonction en temps réel, vous pouvez atténuer le trafic abusif en traitant les résultats par lots : publiez les résultats dans un Pub/Sub sujet, et traitez les résultats à intervalles réguliers avec une fonction planifiée.
Comprendre les clés API
Les clés API pour les services Firebase ne sont pas secrètes
Les clés API pour les services Firebase identifient uniquement votre projet et votre application Firebase auprès de ces services. L'autorisation est gérée via les autorisations IAM Google Cloud, Firebase Security Rules, et Firebase App Check.
Toutes les clés API provisionnées par Firebase sont automatiquement limitées aux API liées à Firebase. Si la configuration de votre application suit les consignes de cette page, les clés API limitées aux services Firebase n'ont pas besoin d'être traitées comme des secrets, et vous pouvez les inclure en toute sécurité dans votre code ou vos fichiers de configuration.
Configurer des restrictions de clé API
Si vous utilisez des clés API pour d'autres services Google, assurez-vous d'appliquer des restrictions de clé API pour limiter vos clés API à vos clients d'application et aux API que vous utilisez.
Utilisez vos clés API provisionnées par Firebase uniquement pour les API liées à Firebase. Si votre application utilise d'autres API (par exemple, l'API Places pour Maps ou l' Gemini Developer API), utilisez une clé API distincte et limitez-la à l'API applicable.
Garder les clés de serveur FCM secrètes
Contrairement aux clés API pour les services Firebase, les clés de serveur FCM (utilisées par l' ancienne API HTTP FCM) sont sensibles et doivent rester secrètes.
Garder les clés de compte de service secrètes
Contrairement aux clés API pour les services Firebase, les clés privées de compte de service (utilisées par le Firebase Admin SDK) sont sensibles et doivent rester secrètes.
Firebase Security Rules
Initialiser les règles en mode production ou verrouillé
Lorsque vous configurez Cloud Firestore, Realtime Database et Cloud Storage, initialisez vos Firebase Security Rules pour refuser tout accès par défaut, puis ajoutez des règles qui accordent l'accès à des ressources spécifiques à mesure que vous développez votre application.
Utilisez l'un des paramètres par défaut pour les nouvelles instances de Cloud Firestore (production mode) et Realtime Database (mode verrouillé). Pour Cloud Storage, commencez par une configuration de règles de sécurité comme celle-ci :
rules_version = '2';
service firebase.storage {
match /b/{bucket}/o {
match /{allPaths=**} {
allow read, write: if false;
}
}
}
Les règles de sécurité sont un schéma ; ajoutez des règles lorsque vous ajoutez des documents
N'écrivez pas de règles de sécurité après avoir écrit votre application, comme une tâche de pré-lancement. Écrivez plutôt des règles de sécurité au fur et à mesure que vous écrivez votre application, en les traitant comme un schéma de base de données : chaque fois que vous devez utiliser un nouveau type de document ou une nouvelle structure de chemin d'accès, écrivez d'abord sa règle de sécurité.
Tester les règles de sécurité de manière unitaire avec Local Emulator Suite ; l'ajouter à l'intégration continue
Pour vous assurer que vos règles de sécurité suivent le développement de votre application, testez-les de manière unitaire avec Firebase Local Emulator Suite et ajoutez ces tests à votre pipeline d’intégration continue. Consultez ces guides pour Cloud Firestore et Realtime Database.
Authentification
Authentification personnalisée : générer des jetons JWT à partir d'un environnement approuvé (côté serveur)
Si vous disposez déjà d'un système de connexion sécurisé, qu'il s'agisse d'un système personnalisé ou d'un service tiers, vous pouvez utiliser votre système existant pour vous authentifier auprès des services Firebase. Créez des jetons JWT personnalisés à partir d'un environnement approuvé, puis transmettez-les à votre client, qui les utilise pour s'authentifier (iOS+, Android, Web, Unity, C++).
Pour obtenir un exemple d'utilisation de l'authentification personnalisée avec un fournisseur tiers, consultez l'article de blog Authentifier les utilisateurs dans Firebase avec Okta.
Authentification gérée : les fournisseurs OAuth 2.0 sont les plus sécurisés
Si vous utilisez les fonctionnalités d'authentification gérée de Firebase, les options de fournisseur OAuth 2.0 / OpenID Connect (Google, Facebook, etc.) sont les plus sécurisées. Vous devez prendre en charge un ou plusieurs de ces fournisseurs si vous le pouvez (en fonction de votre base d'utilisateurs).
Authentification par adresse e-mail et mot de passe : définir un quota strict pour le point de terminaison de connexion afin d'empêcher les attaques par force brute
Si vous utilisez le service d'authentification gérée par adresse e-mail et mot de passe de Firebase, réduisez le quota par défaut des points de terminaison identitytoolkit.googleapis.com pour éviter les attaques par force brute. Vous pouvez le faire depuis la
page
de la console Google Cloud.
Authentification par adresse e-mail et mot de passe : activer la protection contre l'énumération des adresses e-mail
Si vous utilisez le service d'authentification gérée par adresse e-mail et mot de passe de Firebase, activez la protection contre l'énumération des adresses e-mail, qui empêche les acteurs malveillants d'abuser des points de terminaison d'authentification de votre projet pour deviner les noms de compte.
Passer à Google Cloud Identity Platform pour l'authentification multifacteur
Pour renforcer la sécurité lors de la connexion, vous pouvez ajouter la prise en charge de l'authentification multifacteur en passant à Google Cloud Identity Platform. Votre code Firebase Authentication existant continuera de fonctionner après la mise à niveau.
Authentification anonyme
N'utiliser l'authentification anonyme que pour l'intégration à chaud
N'utilisez l'authentification anonyme que pour enregistrer l'état de base des utilisateurs avant qu'ils ne se connectent. L'authentification anonyme ne remplace pas la connexion des utilisateurs.
Convertir les utilisateurs vers une autre méthode de connexion s'ils souhaitent que leurs données soient disponibles sur d'autres appareils
Les données d'authentification anonymes ne seront pas conservées si l'utilisateur efface le stockage local ou change d'appareil. Si vous devez conserver les données au-delà des redémarrages de l'application sur un seul appareil, convertissez l'utilisateur en compte permanent.
Utiliser des règles de sécurité qui exigent que les utilisateurs soient passés à un fournisseur de connexion ou qu'ils aient validé leur adresse e-mail
N'importe qui peut créer un compte anonyme dans votre projet. Dans cette optique, protégez toutes les données non publiques à l'aide de règles de sécurité qui nécessitent des méthodes de connexion spécifiques ou des adresses e-mail validées.
Exemple :
allow write: if request.auth.token.firebase.sign_in_provider != "anonymous";
allow write: if request.auth.token.email_verified = true;
Sécurité Cloud Functions
Ne jamais placer d'informations sensibles dans des variables d'environnement
Souvent, dans une application Node.js auto-hébergée, vous utilisez des variables d'environnement pour contenir des informations sensibles telles que des clés privées. Ne le faites pas dans Cloud Functions. Étant donné que Cloud Functions réutilise les environnements entre les appels de fonction, les informations sensibles ne doivent pas être stockées dans l'environnement.
Pour stocker les clés API Firebase (qui ne sont pas secrètes), il vous suffit de les intégrer dans le code.
Si vous utilisez le Firebase Admin SDK dans Cloud Functions, vous n'avez pas besoin de fournir explicitement les identifiants du compte de service, car le Admin SDK peut les acquérir automatiquement lors de l'initialisation.
Si vous appelez des API Google et Google Cloud qui nécessitent des identifiants de compte de service, la bibliothèque Google Auth pour Node.js peut obtenir ces identifiants à partir des identifiants par défaut de l'application, qui sont automatiquement renseignés dans Cloud Functions.
Pour mettre à disposition des clés privées et des identifiants pour les services non Google dans vos Cloud Functions, utilisez Secret Manager.
Chiffrer les informations sensibles
Si vous ne pouvez pas éviter de transmettre des informations sensibles à vos fonctions, vous devez trouver votre propre solution personnalisée pour les chiffrer.
Les fonctions simples sont plus sûres ; si vous avez besoin de complexité, envisagez Cloud Run
Essayez de rendre vos fonctions aussi simples et compréhensibles que possible. La complexité de vos fonctions peut souvent entraîner des bugs difficiles à repérer ou un comportement inattendu.
Si vous avez besoin d'une logique ou de configurations d'environnement complexes, envisagez d'utiliser Cloud Run plutôt que Cloud Functions.
Gestion de l'environnement
Configurer des projets de développement et de préproduction
Configurez des projets Firebase distincts pour le développement, la préproduction et la production. Ne fusionnez pas le code client en production tant qu'il n'a pas été testé par rapport au projet de préproduction.
Limiter l'accès de l'équipe aux données de production
Si vous travaillez avec une équipe plus importante, vous pouvez atténuer les conséquences des erreurs et des violations en limitant l'accès aux données de production à l'aide de rôles IAM prédéfinis ou de rôles IAM personnalisés.
Si votre équipe utilise Firebase Local Emulator Suite (recommandé) pour le développement, vous n'aurez peut-être pas besoin d'accorder un accès plus large au projet de production.
Gestion des bibliothèques
Attention aux fautes d'orthographe dans les bibliothèques ou aux nouveaux responsables
Lorsque vous ajoutez des bibliothèques à votre projet, faites très attention à leur nom et à leurs responsables. Une bibliothèque dont le nom est similaire à celle que vous souhaitez installer peut contenir du code malveillant.
Ne pas mettre à jour les bibliothèques sans comprendre les modifications
Consultez les journaux des modifications de toutes les bibliothèques que vous utilisez avant de les mettre à niveau. Assurez-vous que la mise à niveau apporte une valeur ajoutée et vérifiez que le responsable est toujours une partie en qui vous avez confiance.
Installer les bibliothèques de surveillance en tant que dépendances de développement ou de test
Utilisez une bibliothèque telle que Snyk pour analyser votre projet et détecter les dépendances non sécurisées.
Configurer la surveillance pour Cloud Functions ; la vérifier après les mises à jour de la bibliothèque
Si vous utilisez le Cloud Functions SDK de l'enregistreur, alors vous pouvez surveiller les comportements inhabituels et être alerté, y compris ceux causés par les mises à jour de la bibliothèque.