Pour assurer la sécurité de vos ressources Firebase et des 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éveloppez votre application.
Évitez le trafic abusif
Configurer la surveillance et les alertes pour les services 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 suspectez une attaque sur 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 s'adapter au trafic normal
Cloud Functions s'adapte automatiquement pour répondre aux demandes de votre application, mais en cas d'attaque, cela peut signifier une grosse facture. 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 a des pics de demandes, les quotas se déclenchent souvent et limitent 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 se lancer accidentellement sous DOS lors du développement de Cloud Functions : par exemple, en créant une boucle infinie de déclenchement-écriture. Vous pouvez empêcher ces erreurs d'affecter les services en direct en effectuant votre développement avec la suite d'émulateurs Firebase .
(Et si vous faites accidentellement 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 des 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 pour les 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é d'API
Comme moyen de dissuasion supplémentaire contre un attaquant tentant d'utiliser votre clé API pour usurper des demandes, vous pouvez créer des clés API limitées à vos clients d'application .
Gardez les clés du serveur FCM secrètes
Contrairement aux clés d'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.
Gardez secrètes les clés du compte de service
Contrairement aux clés API pour les services Firebase, les clés privées de compte de service (utilisées par le SDK Admin ) sont sensibles et doivent rester 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 suit :
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 de pré-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 devez utiliser un nouveau type de document ou une nouvelle structure de chemin, écrivez d'abord sa règle de sécurité.
Règles de sécurité des tests unitaires avec Emulator Suite ; l'ajouter à 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 : menthe 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 de confiance, 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 le billet de blog, Authentification 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ée 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 (selon votre base d'utilisateurs).
Authentification e-mail-mot de passe : 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 géré par 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 Google Cloud Console .
Authentification e-mail-mot de passe : Activer la protection de l'énumération des e-mails
Si vous utilisez le service d'authentification géré par e-mail par mot de passe de Firebase, activez la protection de l'é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 compte.
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 l'intégration à chaud
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 à une autre méthode de connexion s'ils veulent les données lorsqu'ils perdent leur téléphone
Les données d'authentification anonymes ne seront pas conservées si l'utilisateur efface le stockage local ou change d'appareil. Si vous avez besoin de conserver des 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 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 cet esprit, 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 example:
allow write: if request.auth.token.firebase.sign_in_provider != "anonymous";
allow write: if request.auth.token.email_verified = true;
Gestion de l'environnement
Monter des projets de développement et de mise en scène
Configurez des projets Firebase distincts pour le développement, la préproduction 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.
Limitez l'accès des équipes 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 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
Faites attention aux fautes d'orthographe de la bibliothèque ou aux nouveaux responsables
Lorsque vous ajoutez des bibliothèques à votre projet, portez une attention particulière au nom de la bibliothèque et de ses mainteneurs. Une bibliothèque portant le même nom que celle que vous avez l'intention d'installer peut contenir du code malveillant.
Ne mettez pas à jour les bibliothèques sans comprendre les changements
Consultez les journaux des 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 des 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.
Configurer la surveillance des fonctions ; vérifiez-le après les mises à jour de la bibliothèque
Si vous utilisez le SDK Cloud Functions logger , vous pouvez surveiller et être alerté des comportements inhabituels, y compris les comportements provoqués par les mises à jour de la bibliothèque.
Sécurité de la fonction 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 fonction, les informations sensibles ne doivent pas être stockées dans l'environnement.
- Pour stocker les clés de l'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 mettre à la disposition de vos fonctions Cloud des clés privées et des identifiants pour des services autres que Google, utilisez Cloud Secret Manager .
Crypter 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 entraîner des bogues difficiles à repérer ou un comportement inattendu.
Si vous avez besoin de configurations complexes de logique ou d'environnement, envisagez d'utiliser Cloud Run au lieu de Cloud Functions.