Scanner de règles Firebase : trouver les règles ouvertes dans Firestore, Realtime Database et Storage

Comment le scanner trouve les règles Firebase ouvertes

Firebase services are reachable at predictable public addresses, so a scanner with no credentials can check each one the way an anonymous visitor would. FixVibe's Firebase check covers all three services independently:

• Firestore. FixVibe finds the project from the deployed app's own Firebase configuration and reports collections that anonymous visitors can read.
• Realtime Database. FixVibe reports a database whose data anonymous visitors can read — often the whole tree at once.
• Cloud Storage. FixVibe reports buckets that anonymous visitors can list. Listable storage is a finding even when individual downloads are denied, because it lets attackers find guessable filenames.

À quoi ressemble réellement le piège du mode test

La documentation de démarrage rapide de Firebase inclut l'un des blocs de règles les plus copiés sur Internet :

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if true;
    }
  }
}

Firebase ajoutait autrefois une expiration automatique de 30 jours sur ces règles. Cela a changé : aujourd'hui les règles persistent indéfiniment à moins que le développeur ne les remplace. Les outils de codage IA — entraînés sur des années de documentation qui inclut le bloc mode test — l'émettent souvent textuellement et disent au développeur « ceci est votre règle de sécurité ». Ce ne l'est pas.

D'autres variantes qui apparaissent en production mais sont tout aussi permissives :

// future-date variant — equivalent to "if true"
allow read, write: if request.time < timestamp.date(2099, 1, 1);

// authenticated-user variant — any signed-in user reads and writes anything
allow read: if true;
allow write: if request.auth != null;

// any-auth variant — any signed-in user owns every document
allow read, write: if request.auth != null;

• Une variante avec horodatage futur : une règle qui autorise tout jusqu'à une date lointaine dans le futur. N'expire effectivement jamais (voir le bloc mis en évidence ci-dessus).
• allow read: if true; allow write: if request.auth != null; — lectures publiques, tout utilisateur authentifié peut écrire.
• allow read, write: if request.auth != null; — tout utilisateur connecté peut lire ou écrire n'importe quel document, y compris les données d'autres utilisateurs.

Que faire quand le scanner trouve une règle ouverte

Les règles Firebase ouvertes sont une urgence en production. La correction a la même forme dans les trois services : limitez chaque règle à request.auth.uid contre un champ de propriétaire explicite. Chaque service a sa propre syntaxe de règles :

Firestore

match /users/{userId} { allow read, write: if request.auth != null && request.auth.uid == userId; }. La liaison de segment de chemin {userId} devient le seul document que l'utilisateur peut toucher.

match /users/{userId} {
  allow read, write: if request.auth != null
                     && request.auth.uid == userId;
}

Base de données en temps réel

{ "rules": { "users": { "$uid": { ".read": "$uid === auth.uid", ".write": "$uid === auth.uid" } } } }. Le joker $uid capture le segment de chemin pour comparaison.

{
  "rules": {
    "users": {
      "$uid": {
        ".read":  "$uid === auth.uid",
        ".write": "$uid === auth.uid"
      }
    }
  }
}

Stockage en nuage

service firebase.storage { match /b/{bucket}/o { match /users/{userId}/{allPaths=**} { allow read, write: if request.auth.uid == userId; } } }. Convention : stockez les fichiers sous users/[uid]/[filename] et laissez le chemin imposer la propriété.

service firebase.storage {
  match /b/{bucket}/o {
    match /users/{userId}/{allPaths=**} {
      allow read, write: if request.auth.uid == userId;
    }
  }
}

Deploy rules via the Firebase CLI: firebase deploy --only firestore:rules, firebase deploy --only database, firebase deploy --only storage. Verify the new rules are in production by re-running the FixVibe scan — the open-rules finding should clear.

firebase deploy --only firestore:rules
firebase deploy --only database
firebase deploy --only storage

Comment cela se compare aux outils intégrés de Firebase

La console Firebase vous montre les règles actuelles mais ne les audite pas contre le comportement runtime. Le simulateur de règles Firebase vous permet de tester la logique des règles contre des requêtes synthétiques — utile mais local. Ni l'un ni l'autre des outils ne vous dit ce que vos règles de production retournent réellement à un attaquant anonyme sur l'Internet public. Un scanner externe comme FixVibe (ou Burp Suite avec configuration manuelle) est la seule chose qui sonde sous le même angle qu'un attaquant. App Check de Google atténue les abus mais ne remplace pas des règles correctement limitées.

Questions fréquentes

Étapes suivantes

Run a free FixVibe scan against your production URL — the Firebase rules check runs on every plan and flags open rules across Firestore, Realtime Database, and Cloud Storage. For a deeper explainer on the allow read, write: if true pattern specifically, see Firebase allow read, write: if true explained. For the umbrella view across Supabase, Firebase, Clerk, and Auth0, read BaaS misconfiguration scanner.