Les règles de sécurité Firebase fournissent un mécanisme granulaire appliqué par le serveur pour protéger les données dans Firestore, la base de données en temps réel et le stockage cloud [S1]. Étant donné que les applications Firebase interagissent souvent avec ces services cloud directement du côté client, ces règles représentent la seule barrière empêchant l'accès non autorisé aux données backend [S1].
Impact des règles permissives
Des règles mal configurées peuvent entraîner une exposition importante des données [S2]. Si les règles sont définies pour être trop permissives (par exemple, en utilisant les paramètres par défaut du « mode test » qui autorisent un accès global), tout utilisateur connaissant l'ID du projet peut lire, modifier ou supprimer l'intégralité du contenu de la base de données [S2]. Cela contourne toutes les mesures de sécurité côté client et peut entraîner la perte d’informations utilisateur sensibles ou une interruption totale du service [S2].
Cause première : Logique d'autorisation insuffisante
La cause première de ces vulnérabilités est généralement l'incapacité à mettre en œuvre des conditions spécifiques qui restreignent l'accès en fonction de l'identité de l'utilisateur ou des attributs de ressources [S3]. Les développeurs laissent fréquemment les configurations par défaut actives dans les environnements de production qui ne valident pas l'objet request.auth [S3]. Sans évaluer request.auth, le système ne peut pas faire la distinction entre un utilisateur légitime authentifié et un demandeur anonyme [S3].
Correction technique
La sécurisation d'un environnement Firebase nécessite de passer d'un accès ouvert à un modèle de principe du moindre privilège.
- Appliquer l'authentification : assurez-vous que tous les chemins sensibles nécessitent une session utilisateur valide en vérifiant si l'objet
request.authn'est pas nul [S3]. - Implémentez l'accès basé sur l'identité : configurez des règles qui comparent l'UID de l'utilisateur (
request.auth.uid) à un champ du document ou à l'ID du document lui-même pour garantir que les utilisateurs ne peuvent accéder qu'à leurs propres données [S3]. - Étendue granulaire des autorisations : évitez les caractères génériques globaux pour les collections. Au lieu de cela, définissez des règles spécifiques pour chaque collection et sous-collection afin de minimiser la surface d'attaque potentielle [S2].
- Validation via Emulator Suite : utilisez la suite d'émulateurs Firebase pour tester les règles de sécurité localement. Cela permet de vérifier la logique de contrôle d'accès par rapport à diverses personnalités d'utilisateurs avant le déploiement dans un environnement réel [S2].
Comment FixVibe le teste
FixVibe l'inclut désormais en tant qu'analyse BaaS en lecture seule. baas.firebase-rules extrait la configuration Firebase à partir de bundles JavaScript de même origine, y compris les formes de bundle initializeApp(...) modernes, puis vérifie la base de données en temps réel, Firestore et le stockage Firebase avec des requêtes en lecture seule non authentifiées. Pour Firestore, il essaie d'abord de lister la collection racine ; lorsque la liste est bloquée, il sonde également les noms de collections sensibles courants tels que users, accounts, customers, orders, payments, messages, admin et settings. Il ne signale que les lectures ou listes anonymes réussies et n'écrit, ne supprime ni ne stocke le contenu des documents client.