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

Les services Firebase exposent des formes d'URL bien connues et prévisibles. Un scanner sans identifiants peut sonder chacune et observer si les lectures anonymes réussissent. Le check baas.firebase-rules de FixVibe lance trois sondages indépendants — un par service Firebase :

• <strong>Firestore.</strong> The scanner extracts the project ID from the deployed app's bundle (it's in <code>firebase.initializeApp({ projectId: ... })</code>), then issues <code>GET https://firestore.googleapis.com/v1/projects/[project-id]/databases/(default)/documents/[collection]:listDocuments</code> against common collection names. A <code>200 OK</code> with documents in the response means <code>allow read</code> is permissive.
• Realtime Database. Le scanner sonde https://[project-id]-default-rtdb.firebaseio.com/.json. Si la racine est lisible anonymement, la réponse est l'arbre complet de la base de données en JSON. Un test plus conservateur interroge .json?shallow=true, qui retourne seulement les clés de premier niveau — un résultat dans les deux cas.
• Cloud Storage. Le scanner interroge https://firebasestorage.googleapis.com/v0/b/[project-id].appspot.com/o. Si la réponse liste des noms de fichiers sans authentification, le bucket est listable anonymement. Un stockage listable est un résultat même lorsque les téléchargements de fichiers individuels sont refusés — les attaquants énumèrent le bucket pour trouver des noms de fichiers devinables.

À 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;
}

Realtime Database

<code>{ "rules": { "users": { "$uid": { ".read": "$uid === auth.uid", ".write": "$uid === auth.uid" } } } }</code>. The <code>$uid</code> wildcard captures the path segment for comparison.

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

Cloud Storage

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;
    }
  }
}

Déployez les règles via la CLI Firebase : firebase deploy --only firestore:rules, firebase deploy --only database, firebase deploy --only storage. Vérifiez que les nouvelles règles sont en production en relançant le scan FixVibe — le résultat baas.firebase-rules devrait disparaître.

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

Lancez un scan FixVibe gratuit contre votre URL de production — le check baas.firebase-rules est dans tous les plans et signale les règles ouvertes dans Firestore, Realtime Database et Cloud Storage. Pour une explication plus approfondie du motif allow read, write: if true spécifiquement, voir Firebase allow read, write: if true expliqué. Pour la vue d'ensemble sur Supabase, Firebase, Clerk et Auth0, lisez Scanner de mauvaises configurations BaaS.