Vérifiez vos règles de sécurité Firebase face à 26 erreurs courantes
Collez vos règles Firestore, Firebase Storage ou Realtime Database. Le vérificateur lit le texte et montre quels chemins laissent n’importe qui lire ou écrire.
Résultat
Il s’agit d’une analyse statique du texte collé. Elle ne voit ni les custom claims, ni App Check, ni la forme des données, ni les règles qui n’ont jamais été déployées ; la note couvre seulement ce que les 26 vérifications peuvent lire.
Ce que cette vérification ne peut pas voir
Le vérificateur lit uniquement le texte collé. Il ne voit ni les custom claims, ni App Check, ni la forme de vos données, ni les règles qui n’ont jamais été déployées : un résultat propre ne veut donc pas dire que le projet est sûr.
Les 26 vérifications
| Vérification | ID | Service | Gravité |
|---|---|---|---|
| N’importe qui peut écrire dans Firestore | fs-open-write | Firestore | Critique |
| N’importe qui peut lire dans Firestore | fs-open-read | Firestore | Moyenne |
| Un match à joker récursif est ouvert | fs-recursive-wildcard-open | Firestore | Critique |
| Règles du mode test avec date d’expiration | fs-test-mode-expiry | Firestore | Critique |
| Tout utilisateur connecté peut écrire | fs-auth-only-write | Firestore | Élevée |
| Tout utilisateur connecté peut lire | fs-auth-only-read | Firestore | Moyenne |
| E-mail jugé fiable sans email_verified | fs-email-unverified | Firestore | Moyenne |
| Rôle lu dans les données de la requête | fs-role-from-request | Firestore | Élevée |
| Un joker large masque des règles plus strictes | fs-wildcard-shadow | Firestore | Élevée |
| Les utilisateurs peuvent écrire leur propre rôle (heuristique) | fs-self-role-write | Firestore | Élevée |
| Les écritures acceptent n’importe quel champ (heuristique) | fs-write-no-field-guard | Firestore | Moyenne |
| read n’est pas séparé en get et list | fs-read-not-split | Firestore | Info |
| Pas de refus par défaut explicite | fs-no-default-deny | Firestore | Info |
| Les règles Firestore n’ont pas pu être lues | fs-parse-error | Firestore | Info |
| N’importe qui peut lire les fichiers Storage | st-open-read | Storage | Moyenne |
| N’importe qui peut écrire dans Storage | st-open-write | Storage | Critique |
| Le match {allPaths=**} est ouvert | st-recursive-wildcard-open | Storage | Critique |
| Tout utilisateur connecté peut écrire dans Storage | st-auth-only-write | Storage | Élevée |
| Les règles Storage n’ont pas pu être lues | st-parse-error | Storage | Info |
| Toute la base est lisible par n’importe qui | db-root-read-open | Realtime Database | Critique |
| Toute la base est modifiable par n’importe qui | db-root-write-open | Realtime Database | Critique |
| Un nœud est lisible par n’importe qui | db-open-read | Realtime Database | Moyenne |
| Un nœud est modifiable par n’importe qui | db-open-write | Realtime Database | Élevée |
| Une règle d’enfant est annulée par son parent | db-cascade-override | Realtime Database | Élevée |
| Tout utilisateur connecté peut lire ou écrire toute la base de données | db-auth-only-root | Realtime Database | Élevée |
| Les règles Realtime Database n’ont pas pu être lues | db-parse-error | Realtime Database | Info |
Questions
Que regarde le vérificateur de règles Firebase ?
Il lit les règles de sécurité Firebase que vous collez pour Firestore, Cloud Storage et Realtime Database et cherche les règles qui laissent n’importe qui lire ou écrire, celles qui exigent seulement un utilisateur connecté, la confiance accordée aux données du client et des schémas voisins.
Le texte de mes règles est-il conservé ?
Non. Les règles sont traitées en mémoire sur le réseau de Cloudflare et supprimées dès l’envoi de la réponse. Rien n’est enregistré ni journalisé avec le texte.
Combien puis-je coller ?
Jusqu’à 48,000 caractères au total sur les trois champs. Si vos règles sont plus longues, collez la partie que vous voulez faire vérifier.
Pourquoi une règle de lecture publique peut-elle être correcte ?
Certaines données sont publiques par choix, comme un catalogue de produits ou des articles de blog. Pour Firestore et Storage, le vérificateur compte une lecture sans condition comme un problème moyen et retire 10 points, car il ne peut pas savoir si les données sont privées. Si les données sont publiques par choix, vous pouvez accepter ce coût. Seulement à la racine de la Realtime Database, il note une lecture ouverte plus sévèrement.
Que sont les règles du mode test ?
Quand vous créez une base Firestore en mode test, la console écrit une règle qui autorise tout jusqu’à une échéance, avec request.time. Jusque-là, n’importe qui peut lire et écrire ; ensuite tout est refusé et l’application cesse de fonctionner. Remplacez-la par de vraies conditions avant le lancement.
Comment les règles de Realtime Database se propagent-elles en cascade ?
Dans Realtime Database, une règle qui accorde l’accès s’applique à tout ce qui se trouve en dessous, et un enfant ne peut pas la retirer. Une règle plus stricte sur un enfant sous un parent permissif ne s’applique jamais, c’est pourquoi le vérificateur la signale.
Que signifie la note ?
Elle résume seulement ce que les vérifications peuvent lire dans le texte collé : un score de 100 moins une pénalité par vérification échouée, fixée par le problème le plus grave que cette vérification a trouvé, et tout problème critique donne F. Un point moyen peut aussi être une heuristique qui demande de vérifier à la main, car le texte seul ne montre pas s’il s’agit d’un vrai problème. Un A ne prouve pas que le projet est sûr, car les custom claims, App Check et les données elles-mêmes sont hors de portée.