Firebase allow read, write: if true expliqué : ce que cela fait et comment le corriger

La syntaxe, ligne par ligne

Un document complet de règles Firestore en mode test fait six lignes :

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

Décodé :

• rules_version = '2'; sélectionne le moteur de règles v2 (actuel). Les anciennes règles v1 sont dépréciées.
• service cloud.firestore limite le bloc à Firestore. Realtime Database utilise une syntaxe basée JSON différente ; Cloud Storage utilise service firebase.storage.
• match /databases/{database}/documents lie la base de données spéciale (default) (la plupart des projets n'en ont qu'une).
• match /{document=**} est un joker récursif. Le ** correspond à n'importe quel chemin de n'importe quelle profondeur. Combiné à {document}, cela capture chaque document dans chaque collection — une unique clause match gouvernant toute la base de données.
• allow read, write: if true; est le corps de la règle. À la fois read et write sont autorisés ; la condition if true est, eh bien, toujours vraie. read couvre les opérations get et list ; write couvre create, update et delete.

Effet net : tout client avec l'ID de projet Firebase et le bon SDK peut lire ou écrire n'importe quel document dans n'importe quelle collection. L'authentification n'est pas requise. Les limites de taux ne sont pas appliquées.

Pourquoi Firebase livre ceci comme défaut

Firebase veut que vous codiez dans les 30 premières secondes après la création d'un projet. L'alternative — vous forcer à écrire une règle correcte avant que toute lecture ou écriture ne fonctionne — bloquerait l'onboarding. Donc la console offre deux options lorsque vous créez une base de données : Mode production (tout refuser, vous écrivez les règles) ou Mode test (tout autoriser pendant 30 jours). La plupart des développeurs cliquent sur mode test, puis oublient d'y revenir. Les anciens projets avaient le minuteur de 30 jours ; les projets actuels ont une règle if true indéfinie sans expiration automatique.

Le problème structurel : les outils de codage IA s'entraînent sur de la documentation, des tutoriels et des réponses Stack Overflow qui montrent des règles en mode test. Quand vous demandez à Cursor ou Claude Code « comment configurer Firebase », la réponse inclut souvent le bloc exact allow read, write: if true comme s'il s'agissait de la règle de production. L'IA ne sait pas — et n'est pas invitée à savoir — que cette règle n'est pas sûre pour la production.

Ce qu'un attaquant voit

Concretely, an attacker who knows your Firebase project ID (it ships in every deployed app's configuration) can list every collection and read every document with plain, unauthenticated requests to Firebase's public REST API.

Once the collections are listed, every document in them can be read. Nothing slows this down, because if true rules accept anonymous traffic.

Sur le chemin d'écriture : un seul POST avec {fields} crée un nouveau document. Les attaquants peuvent polluer vos collections avec des déchets, défigurer des pages côté utilisateur qui lisent depuis Firestore ou utiliser votre base de données comme un broker de messages gratuit — votre facture d'utilisation explose, vous enquêtez, la facture explique le problème.

Quatre remplacements sûrs pour la production

Choisissez le remplacement qui correspond au modèle de données de votre application. Les quatre supposent que vous avez une authentification utilisateur (Firebase Auth ou tout fournisseur qui émet un token ID Firebase) :

Option 1 : documents possédés par l'utilisateur

Motif SaaS le plus courant. Les documents vivent sous /users/{userId}/... et seul le propriétaire peut les toucher. match /users/{userId}/{document=**} { allow read, write: if request.auth != null && request.auth.uid == userId; }

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

Option 2 : champ propriétaire sur chaque document

Quand les documents vivent dans des collections plates (non imbriqués sous l'ID utilisateur), stockez un champ owner_uid et vérifiez-le. match /posts/{postId} { allow read: if resource.data.public == true || resource.data.owner_uid == request.auth.uid; allow write: if request.auth.uid == resource.data.owner_uid; }

match /posts/{postId} {
  allow read:  if resource.data.public == true
              || resource.data.owner_uid == request.auth.uid;
  allow write: if request.auth.uid == resource.data.owner_uid;
}

Option 3 : isolation multi-tenant par org

Pour SaaS B2B avec données limitées par org. Stockez un champ org_id sur chaque document et vérifiez-le contre le custom claim de l'utilisateur. allow read, write: if request.auth.token.org_id == resource.data.org_id;. Nécessite de définir le custom claim lors de l'inscription via le SDK Admin Firebase.

allow read, write: if request.auth.token.org_id == resource.data.org_id;

Option 4 : contenu public en lecture seule

Pour le contenu marketing, les profils publics, les catalogues de produits — tout ce qui est véritablement en lecture publique mais en écriture admin uniquement. match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }. Le custom claim admin n'est défini que sur les comptes admin.

match /products/{productId} {
  allow read:  if true;
  allow write: if request.auth.token.admin == true;
}

Requête d'audit rapide

Avant de corriger, vérifiez si if true est effectivement actif. Ouvrez Console Firebase → Firestore → Rules et cherchez if true. Si vous le trouvez n'importe où en dehors d'un commentaire, vous avez un résultat de règle ouverte. Le simulateur de règles dans la même UI vous permet de rejouer la requête de l'attaquant localement — collez un GET /users/somebody anonyme et confirmez que le simulateur retourne Allowed.

External confirmation: run a FixVibe scan against your production URL. FixVibe checks your Firestore, Realtime Database, and Storage rules from the outside and reports what an attacker would find — independent of what the Firebase Console shows.

Questions fréquentes

Étapes suivantes

Run a FixVibe scan against your production URL — it confirms whether if true is currently exploitable from the public internet. For how the scanner covers Realtime Database and Storage as well, see Firebase rules scanner. For the equivalent class of misconfiguration on Supabase, read Supabase RLS scanner.