Pour assurer la sécurité de vos ressources Firebase et des données de vos utilisateurs, suivez ces directives. Tous les éléments ne s'appliqueront pas nécessairement à vos besoins, mais gardez-les à l'esprit lorsque vous développez votre application.
Évitez le trafic abusif
Configurer la surveillance et les alertes pour les services 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 contre votre application, contactez le support dès que possible pour lui faire savoir ce qui se passe.
Activer la vérification des applications
Pour vous assurer que seules vos applications peuvent accéder à vos services backend, activez App Check pour chaque service qui le prend en charge.
Configurez vos fonctions Cloud pour qu'elles s'adaptent au trafic normal
Cloud Functions s'adapte automatiquement pour répondre aux demandes de votre application, mais en cas d'attaque, cela peut entraîner une facture importante. Pour éviter cela, vous pouvez limiter le nombre d'instances simultanées d'une fonction en fonction du trafic normal de votre application.
Configurez des alertes pour être averti lorsque les limites sont presque atteintes
Si votre service connaît des pics de demandes, des quotas entreront souvent en vigueur et limiteront automatiquement le trafic vers votre application. Assurez-vous de surveiller votre tableau de bord d'utilisation et de facturation , mais vous pouvez également définir des alertes budgétaires sur votre projet pour être averti lorsque l'utilisation des ressources dépasse les attentes.
Empêcher les auto-DOS : tester les fonctions localement avec les émulateurs
Il peut être facile de vous effectuer un DOS accidentellement lors du développement de Cloud Functions : par exemple, en créant une boucle d'écriture de déclenchement infinie. Vous pouvez éviter que ces erreurs n'affectent les services en direct en effectuant votre développement avec la suite d'émulateurs Firebase .
(Et si vous faites accidentellement un DOS vous-même, annulez le déploiement de votre fonction en la supprimant de index.js puis en exécutant
Là où la réactivité en temps réel est moins importante, la structure fonctionne 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 sujet Pub/Sub 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
Firebase utilise les clés API uniquement pour identifier le projet Firebase de votre application auprès des services Firebase, et non pour contrôler l'accès à la base de données ou aux données Cloud Storage, ce qui est effectué à l'aide des règles de sécurité Firebase . Pour cette raison, vous n'avez pas besoin de traiter les clés API des services Firebase comme des secrets et vous pouvez les intégrer en toute sécurité dans le code client. En savoir plus sur les clés API pour Firebase .
Configurer la portée de la clé API
Pour dissuader davantage un attaquant tentant d'utiliser votre clé API pour usurper des requêtes, vous pouvez créer des clés API adaptées aux clients de votre application .
Gardez secrètes les clés du serveur FCM
Contrairement aux clés API pour les services Firebase, les clés du serveur FCM (utilisées par l' ancienne API HTTP FCM ) sont sensibles et doivent être gardées secrètes.
Garder secrètes les clés du compte de service
Contrairement aux clés API pour les services Firebase, les clés privées du compte de service (utilisées par le SDK Admin ) sont sensibles et doivent être gardées secrètes.
Règles de sécurité
Initialiser les règles en mode production ou verrouillé
Lorsque vous configurez Cloud Firestore, Realtime Database et Cloud Storage, initialisez vos règles de sécurité pour refuser tout accès par défaut et ajoutez des règles qui accordent l'accès à des ressources spécifiques au fur et à mesure que vous développez votre application.
C'est l'un des paramètres par défaut pour les nouvelles instances de Cloud Firestore (mode production) et Realtime Database (mode verrouillé). Choisissez cette option lors de la configuration d'une nouvelle instance de base de données.
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 ; ajouter 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 sorte de tâche préalable au lancement. Au lieu de cela, écrivez 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 avez besoin d'utiliser un nouveau type de document ou une nouvelle structure de chemin, écrivez d'abord sa règle de sécurité.
Testez les règles de sécurité avec Emulator Suite ; ajoutez-le à CI
Pour vous assurer que vos règles de sécurité suivent le développement de votre application, testez unitairement vos règles avec la suite d'émulateurs Firebase et ajoutez ces tests à votre pipeline CI. Consultez ces guides pour Cloud Firestore et Realtime Database .
Authentification
Authentification personnalisée : créer des JWT à partir d'un environnement de confiance (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 JWT personnalisés à partir d'un environnement fiable, puis transmettez les jetons à votre client, qui utilise le jeton pour s'authentifier ( iOS+ , Android , Web , Unity , C++ ).
Pour un exemple d'utilisation de l'authentification personnalisée avec un fournisseur tiers, consultez l'article de blog Authentifier avec Firebase à l'aide d'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ées de Firebase, les options du 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 mot de passe de courrier électronique : définissez 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 par mot de passe de messagerie géré de Firebase, resserrez le quota par défaut des points de terminaison identitytoolkit.googleapis.com pour empêcher les attaques par force brute. Vous pouvez le faire depuis la page de l'API dans la console Google Cloud .
Authentification par mot de passe de courrier électronique : activer la protection par énumération de courrier électronique
Si vous utilisez le service d'authentification par mot de passe de messagerie géré de Firebase, activez la protection par énumération des e-mails , qui empêche les acteurs malveillants d'abuser des points de terminaison d'authentification de votre projet pour deviner les noms de comptes.
Passez à Cloud Identity Platform pour l'authentification multifacteur
Pour plus de sécurité lors de la connexion, vous pouvez ajouter la prise en charge de l'authentification multifacteur en effectuant une mise à niveau vers Cloud Identity Platform . Votre code d'authentification Firebase existant continuera de fonctionner après la mise à niveau.
Authentification anonyme
Utilisez uniquement l'authentification anonyme pour une intégration chaleureuse
Utilisez uniquement l'authentification anonyme pour enregistrer l'état de base des utilisateurs avant qu'ils ne se connectent réellement. L'authentification anonyme ne remplace pas la connexion des utilisateurs.
Convertissez les utilisateurs vers une autre méthode de connexion s'ils souhaitent obtenir les données lorsqu'ils perdent leur téléphone
Les données d'authentification anonymes ne persisteront pas si l'utilisateur efface le stockage local ou change de périphérique. Si vous devez conserver les données au-delà du redémarrage de l'application sur un seul appareil, convertissez l'utilisateur en compte permanent .
Utilisez des règles de sécurité qui exigent que les utilisateurs se soient convertis en fournisseur de connexion ou aient vérifié 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 avec des règles de sécurité qui nécessitent des méthodes de connexion spécifiques ou des adresses e-mail vérifiées .
Par exemple:
allow write: if request.auth.token.firebase.sign_in_provider != "anonymous";
allow write: if request.auth.token.email_verified = true;
Gestion de l'environnement
Mettre en place des projets de développement et de mise en scène
Configurez des projets Firebase distincts pour le développement, la préparation et la production. Ne fusionnez pas le code client avec la production tant qu'il n'a pas été testé par rapport au projet intermédiaire.
Limiter l’accès des équipes aux données de production
Si vous travaillez avec une équipe plus grande, 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 prédéfinis ou de rôles IAM personnalisés.
Si votre équipe utilise la suite d'émulateurs pour le développement, vous n'aurez peut-être pas besoin d'accorder un accès plus large au projet de production.
Gestion de la bibliothèque
Méfiez-vous des fautes d'orthographe de la bibliothèque ou des nouveaux responsables
Lorsque vous ajoutez des bibliothèques à votre projet, portez une attention particulière au nom de la bibliothèque et de ses responsables. Une bibliothèque portant le même nom que celle que vous avez l'intention d'installer pourrait contenir du code malveillant.
Ne mettez pas à jour les bibliothèques sans comprendre les changements
Consultez les journaux de modifications de toutes les bibliothèques que vous utilisez avant de procéder à la mise à niveau. Assurez-vous que la mise à niveau ajoute de la valeur 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 à la recherche de dépendances non sécurisées.
Mettre en place la surveillance des fonctions ; vérifiez-le après les mises à jour de la bibliothèque
Si vous utilisez le SDK de l'enregistreur Cloud Functions , vous pouvez surveiller et être alerté de tout comportement inhabituel, y compris celui provoqué par les mises à jour de bibliothèque.
Sécurité des fonctions Cloud
Ne placez jamais d'informations sensibles dans les variables d'environnement d'une fonction Cloud.
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 faites pas cela dans Cloud Functions . Étant donné que Cloud Functions réutilise les environnements entre les appels de fonctions, 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 , intégrez-les simplement dans le code.
- Si vous utilisez le SDK Firebase Admin dans une fonction Cloud, vous n'avez pas besoin de fournir explicitement les informations d'identification du compte de service, car le SDK peut les acquérir automatiquement lors de l'initialisation.
- Si vous appelez des API Google et Google Cloud qui nécessitent des informations d'identification de compte de service, la bibliothèque Google Auth pour Node.js peut obtenir ces informations d'identification à partir des informations d'identification par défaut de l'application , qui sont automatiquement renseignées dans Cloud Functions.
- Pour rendre les clés privées et les informations d'identification des services non Google disponibles pour vos fonctions Cloud, utilisez Cloud Secret Manager .
Chiffrer les informations sensibles
Si vous ne pouvez pas éviter de transmettre des informations sensibles à votre fonction Cloud, vous devez proposer votre propre solution personnalisée pour chiffrer les informations.
Les fonctions simples sont plus sûres ; si vous avez besoin de complexité, pensez à Cloud Run
Essayez de garder vos fonctions Cloud aussi simples et compréhensibles que possible. La complexité de vos fonctions peut souvent conduire à des bugs difficiles à détecter ou à des comportements inattendus.
Si vous avez besoin de configurations logiques ou d'environnement complexes, envisagez d'utiliser Cloud Run au lieu de Cloud Functions.