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

Concrètement, un attaquant qui connaît votre ID de projet Firebase (extractible du bundle de n'importe quelle application déployée en 30 secondes) et exécute ce qui suit peut lister chaque document dans chaque collection :

Une seule requête curl non authentifiée suffit pour énumérer chaque collection. Voir le bloc mis en évidence ci-dessous.

curl 'https://firestore.googleapis.com/v1/projects/[project-id]/databases/(default)/documents:listCollectionIds' \
  -X POST \
  -H 'Content-Type: application/json' \
  -d '{}'

La réponse est la liste complète des collections de premier niveau. Pour chaque collection, une seconde requête renvoie les documents. Il n'y a pas de limite de taux sur ce chemin parce que les règles if true acceptent le trafic anonyme. Nous avons vu des bases de données Firebase avec des millions de documents énumérées en moins d'une heure.

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.

Confirmation externe : lancez un scan FixVibe contre votre URL de production. Le check baas.firebase-rules sonde vos règles Firestore, Realtime Database et Storage et signale le même résultat qu'un attaquant découvrirait — indépendamment de ce que montre la console Firebase.

Questions fréquentes

Étapes suivantes

Lancez un scan FixVibe contre votre URL de production — le check baas.firebase-rules confirme si if true est actuellement exploitable depuis l'Internet public. Pour les mécanismes du scanner et les détections parallèles pour Realtime Database et Storage, voir Scanner de règles Firebase. Pour la classe équivalente de mauvaise configuration sur Supabase, lisez Scanner RLS Supabase.