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 exigences, mais gardez-les à l'esprit lorsque vous développez votre application.
Éviter le trafic abusif
Configurer la surveillance et les alertes pour les services de backend
Pour détecter le trafic abusif, comme 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 pensez qu'une attaque a été lancée contre votre application, contactez l'assistance dès que possible pour l'en informer.
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.
Configurer votre Cloud Functions pour qu'il s'adapte au trafic normal
Cloud Functions s'adapte automatiquement 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 enregistre des pics de requêtes, des quotas sont souvent appliqués et le trafic vers votre application est automatiquement limité. Veillez à surveiller votre tableau de bord "Utilisation et 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 attaques DOS automatiques: testez les fonctions localement avec les émulateurs
Il peut être facile de se DOS accidentellement lors du développement de Cloud Functions: par exemple, en créant une boucle d'écriture de déclencheur infinie. Vous pouvez éviter que ces erreurs n'affectent les services en direct en effectuant votre développement avec Firebase Local Emulator Suite.
Si vous vous êtes accidentellement DOS, désinstallez votre fonction en la supprimant de index.js, puis exécutez 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 limiter le trafic abusif en traitant les résultats par lot: publiez les résultats dans un sujet Pub/Sub et traitez-les à intervalles réguliers avec une fonction planifiée.
Comprendre les clés API
Les clés API des services Firebase ne sont pas secrètes
Firebase n'utilise les clés API que 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 se fait à l'aide de Firebase Security Rules. 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 des restrictions de clé API
Pour dissuader un pirate informatique d'essayer d'utiliser votre clé API pour falsifier des requêtes, vous pouvez ajouter des restrictions de clé API pour limiter vos clés API aux clients de votre application et aux API que vous utilisez.
Conserver les clés de serveur FCM de manière sécurisée
Contrairement aux clés API des services Firebase, les clés de serveur FCM (utilisées par l'ancienne API HTTP FCM) sont sensibles et doivent être gardées 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 du compte de service (utilisées par Firebase Admin SDK) sont sensibles et doivent être gardées secrètes.
Firebase Security Rules
Initialiser des règles en mode production ou verrouillé
Lorsque vous configurez Cloud Firestore, Realtime Database et Cloud Storage, initialisez votre 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 lorsque vous développez votre application.
Utilisez l'un des paramètres par défaut pour les nouvelles instances de Cloud Firestore (mode production) et Realtime Database (mode verrouillé). Pour Cloud Storage, commencez par une configuration de règles de sécurité semblable à 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 sorte de tâche de prélancement. Écrivez plutôt des règles de sécurité lorsque vous écrivez votre application, en les considérant 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é avec Local Emulator Suite et les ajouter à la CI
Pour vous assurer que vos règles de sécurité évoluent avec le développement de votre application, effectuez des tests unitaires avec Firebase Local Emulator Suite et ajoutez ces tests à votre pipeline de CI. Consultez ces guides pour Cloud Firestore et Realtime Database.
Authentification
Authentification personnalisée: créez 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 avec les services Firebase. Créez des jetons JWT personnalisés à partir d'un environnement sécurisé, puis transmettez-les à votre client, qui les utilise pour s'authentifier (iOS+, Android, Web, Unity, C++).
Pour voir 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ées de Firebase, les options de fournisseur OAuth 2.0 / OpenID Connect (Google, Facebook, etc.) sont les plus sécurisées. Si possible, vous devez prendre en charge un ou plusieurs de ces fournisseurs (selon votre base d'utilisateurs).
Authentification par e-mail et mot de passe: définissez un quota strict pour le point de terminaison de connexion afin d'éviter les attaques par force brute.
Si vous utilisez le service d'authentification par e-mail et mot de passe géré de Firebase, resserrez 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 API Identity Toolkit de la console Google Cloud.
Authentification par adresse e-mail/mot de passe: activez la protection contre l'énumération d'adresses e-mail
Si vous utilisez le service d'authentification par e-mail et mot de passe géré de Firebase, activez la protection contre l'énumération des e-mails, qui empêche les acteurs malveillants d'utiliser les 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'utilisez l'authentification anonyme que pour l'intégration guidée
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 persistent pas si l'utilisateur vide l'espace de 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.
Utilisez des règles de sécurité qui exigent que les utilisateurs aient migré vers un fournisseur de connexion ou aient validé leur adresse e-mail.
N'importe qui peut créer un compte anonyme dans votre projet. Gardez cela à l'esprit et protégez toutes les données non publiques à l'aide de règles de sécurité qui exigent 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é de Cloud Functions
N'incluez jamais d'informations sensibles dans des variables d'environnement.
Dans une application Node.js auto-hébergée, vous utilisez souvent 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 fonction, les informations sensibles ne doivent pas être stockées dans l'environnement.
Pour stocker des clés API Firebase (qui ne sont pas secrètes), il vous suffit de les intégrer au code.
Si vous utilisez Firebase Admin SDK dans Cloud Functions, vous n'avez pas besoin de fournir explicitement les identifiants du compte de service, car 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 à la disposition de votre Cloud Functions les clés privées et les identifiants des services autres que Google, utilisez Secret Manager.
Chiffrer les informations sensibles
Si vous ne pouvez pas éviter de transmettre des informations sensibles à vos fonctions, vous devez élaborer votre propre solution personnalisée pour chiffrer les informations.
Les fonctions simples sont plus sûres. Si vous avez besoin de complexité, envisagez Cloud Run.
Essayez de garder vos fonctions aussi simples et compréhensibles que possible. La complexité de vos fonctions peut souvent entraîner des bugs difficiles à détecter ou un comportement inattendu.
Si vous avez besoin de logiques ou de configurations d'environnement complexes, envisagez d'utiliser Cloud Run au lieu de 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é avec le 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 de la bibliothèque
Attention aux fautes d'orthographe dans les bibliothèques ou aux nouveaux responsables
Lorsque vous ajoutez des bibliothèques à votre projet, soyez particulièrement attentif au nom de la bibliothèque et de ses responsables. Une bibliothèque portant un nom semblable à celui que vous souhaitez installer peut contenir du code malveillant.
Ne mettez pas à jour les bibliothèques sans comprendre les modifications
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 mainteneur est toujours une partie de confiance.
Installer des bibliothèques de surveillance en tant que dépendances de développement ou de test
Utilisez une bibliothèque telle que Snyk pour rechercher les dépendances non sécurisées dans votre projet.
Configurez la surveillance de Cloud Functions. Vérifiez-la après les mises à jour de la bibliothèque.
Si vous utilisez le SDK de journalisation Cloud Functions, vous pouvez surveiller et être alerté en cas de comportement inhabituel, y compris en cas de comportement causé par des mises à jour de bibliothèque.