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évelopperez 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 soupçonnez une attaque sur votre application, contactez l'assistance dès que possible pour l'informer de la situation.
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 évolue automatiquement pour répondre aux besoins 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 vous approchez des limites.
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é. Veillez à surveiller le tableau de bord Utilisation et facturation. Vous pouvez également définir des alertes budgétaires pour votre projet afin d'être averti lorsque l'utilisation des ressources dépasse les prévisions.
Éviter les attaques par déni de service : tester 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. Pour éviter que ces erreurs n'affectent les services en direct, effectuez votre développement avec Firebase Local Emulator Suite.
Si vous vous attaquez accidentellement par déni de service, annulez le déploiement de votre fonction en la supprimant de index.js, puis en exécutant firebase deploy --only functions
Structurez les fonctions de manière défensive lorsque la réactivité en temps réel est moins importante
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 à 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 votre projet et votre application Firebase auprès de ces services. L'autorisation est gérée par 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. Vous pouvez les inclure dans votre code ou vos fichiers de configuration sans risque.
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.
N'utilisez vos clés API provisionnées par Firebase que pour les API liées à Firebase. Si votre application utilise d'autres API (par exemple, l'API Places pour Maps ou Gemini Developer API), utilisez une clé API distincte et limitez-la à l'API applicable.
Conserver les clés de serveur FCM secrètes
Contrairement aux clés API pour les services Firebase, les clés 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 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 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 à mesure que 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 avant le lancement. Écrivez plutôt des règles de sécurité en même temps 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 d'accès, écrivez d'abord sa règle de sécurité.
Tester les règles de sécurité 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 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 JWT à partir d'un environnement fiable (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 l'utiliser 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 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 e-mail et 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 et adresse e-mail géré de Firebase, renforcez le quota par défaut des points de terminaison identitytoolkit.googleapis.com pour éviter les attaques par force brute. Pour ce faire, accédez à la page de l'API Identity Toolkit dans la console Google Cloud.
Authentification par adresse e-mail et mot de passe : activer la protection contre l'énumération d'adresses e-mail
Si vous utilisez le service d'authentification par mot de passe et adresse e-mail géré par Firebase, activez la protection contre l'énumération d'adresses e-mail. Cela empêchera les personnes malintentionnées 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 à 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.
Convertissez les utilisateurs à une autre méthode de connexion s'ils souhaitent accéder à leurs données 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 des 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 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 avec des 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;
Touché de sûreté de Cloud Functions
N'incluez jamais d'informations sensibles dans les 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. N'effectuez pas cette opération 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 Firebase Admin SDK dans un 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 non Google, 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 d'utiliser 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 des comportements inattendus.
Si vous avez besoin d'une logique 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éparation
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 intermédiaire.
Limiter 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 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
Faites attention aux fautes d'orthographe dans les bibliothèques ou aux nouveaux responsables
Lorsque vous ajoutez des bibliothèques à votre projet, portez une attention particulière au nom de la bibliothèque et à ses responsables. Une bibliothèque portant un nom similaire à celle que vous souhaitez installer peut contenir du code malveillant.
Ne mettez pas à jour les bibliothèques sans comprendre les modifications
Avant de mettre à niveau les bibliothèques que vous utilisez, consultez leurs journaux des modifications. Assurez-vous que la mise à niveau apporte une valeur ajoutée et vérifiez que le responsable de la maintenance est toujours une partie de confiance.
Installer les bibliothèques watchdog 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 SDK de journalisation Cloud Functions, vous pouvez surveiller les comportements inhabituels et recevoir des alertes, y compris ceux causés par les mises à jour de la bibliothèque.