// docs / baas security / firebase if-true explainer

Firebase allow read, write: if true explicat: què fa i com corregir-lo

Q: Quina és la diferència entre if true i if request.auth != null ?

if true permet accés anònim — qualsevol persona a internet. if request.auth != null requereix qualsevol usuari amb sessió iniciada, que és millor però encara és incorrecte: qualsevol usuari de la teva aplicació pot llegir les dades de qualsevol altre usuari. Les regles de producció han de delimitar l'usuari específic o l'organització via request.auth.uid == resource.data.owner_uid o similar.

Q: Què passa si la meva aplicació és genuïnament de lectura pública (blog, catàleg de productes)?

Aleshores escriu explícitament allow read: if true; allow write: if false; només a la col·lecció pública — no a totes les col·leccions de la teva base de dades. Fes servir una clàusula match separada per col·lecció i no facis servir mai el comodí recursiu '{'document=**'}' en regles que permetin escriptura.

<code>allow read, write: if true;</code> és la configuració errònia individual més comuna de Firebase en producció. És el valor per defecte de mode test que la consola de Firebase suggereix quan crees una nova base de dades, la regla que les eines de codificació amb IA regeneren a partir de la documentació, i la regla que obre tota la teva base de dades Firestore a qualsevol persona d'internet. Aquest article explica la sintaxi amb precisió, mostra què veu un atacant quan aquesta regla és viva, i et dona quatre substitucions progressivament més estrictes que s'ajusten a diferents casos d'ús.

La sintaxi, línia a línia

Un document complet de regles en mode test de Firestore són sis línies:

firebase

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

Descodificat:

rules_version = '2'; selecciona el motor de regles v2 (l'actual). Les regles v1 més antigues estan obsoletes.
service cloud.firestore delimita el bloc a Firestore. Realtime Database fa servir una sintaxi diferent basada en JSON; Cloud Storage fa servir service firebase.storage.
match /databases/{database}/documents enllaça la base de dades especial (default) (la majoria de projectes només en tenen una).
match /{document=**} és un comodí recursiu. ** coincideix amb qualsevol ruta de qualsevol profunditat. Combinat amb {document}, això captura tots els documents de totes les col·leccions — una sola clàusula match que regeix tota la base de dades.
allow read, write: if true; és el cos de la regla. Tant read com write estan permesos; la condició if true és, evidentment, sempre certa. read cobreix les operacions get i list; write cobreix create, update i delete.

Efecte net: qualsevol client amb l'ID del projecte Firebase i el SDK adequat pot llegir o escriure qualsevol document de qualsevol col·lecció. No es requereix autenticació. No s'apliquen límits de velocitat.

Per què Firebase ofereix això com a valor per defecte

Firebase vol que estiguis programant en els primers 30 segons després de crear un projecte. L'alternativa — fer-te escriure una regla correcta abans que cap lectura o escriptura funcioni — bloquejaria l'onboarding. Així doncs, la consola ofereix dues opcions quan crees una base de dades: Production mode (denegar tot, tu escrius les regles) o Test mode (permetre tot durant 30 dies). La majoria de desenvolupadors fan clic a mode test i després obliden tornar-hi. Els projectes més antics tenien el temporitzador de 30 dies; els actuals tenen una regla if true indefinida sense caducitat automàtica.

El problema estructural: les eines de codificació amb IA s'entrenen amb documentació, tutorials i respostes de Stack Overflow que mostren regles de mode test. Quan demanes a Cursor o Claude Code "com configuro Firebase", la resposta sovint inclou exactament el bloc allow read, write: if true com si fos la regla de producció. La IA no sap — i no se li demana saber — que aquesta regla no és segura per a producció.

Què veu un atacant

Concretament, un atacant que conegui l'ID del teu projecte Firebase (extraïble de qualsevol bundle d'aplicació desplegada en 30 segons) i executi el següent pot llistar tots els documents de totes les col·leccions:

Una sola petició curl no autenticada n'hi ha prou per enumerar totes les col·leccions. Mira el bloc ressaltat a sota.

bash

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

La resposta és la llista completa de col·leccions de nivell superior. Per a cada col·lecció, una segona petició retorna documents. No hi ha límit de velocitat en aquesta ruta perquè les regles if true accepten trànsit anònim. Hem vist bases de dades Firebase amb milions de documents enumerats en menys d'una hora.

Per la ruta d'escriptura: un sol POST amb {fields} crea un document nou. Els atacants poden contaminar les teves col·leccions amb brossa, desfigurar pàgines visibles a l'usuari que llegeixen de Firestore, o fer servir la teva base de dades com a broker de missatges gratuït — la teva factura d'ús es dispara, ho investigues, la factura explica el problema.

Quatre substitucions segures per a producció

Tria la substitució que coincideixi amb el model de dades de la teva aplicació. Totes quatre assumeixen que tens autenticació d'usuaris (Firebase Auth o qualsevol proveïdor que emeti un ID token de Firebase):

Opció 1: Documents propietat de l'usuari

Patró SaaS més comú. Els documents viuen sota /users/{userId}/... i només el propietari els pot tocar. match /users/{userId}/{document=**} { allow read, write: if request.auth != null && request.auth.uid == userId; }

firebase

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

Opció 2: Camp de propietari a cada document

Quan els documents viuen en col·leccions planes (no niades sota l'ID d'usuari), emmagatzema un camp owner_uid i comprova'l. 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; }

firebase

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

Opció 3: Aïllament d'organització multi-tenant

Per a SaaS B2B amb dades delimitades per organització. Emmagatzema un camp org_id a cada document i comprova'l contra el claim personalitzat de l'usuari. allow read, write: if request.auth.token.org_id == resource.data.org_id;. Requereix establir el claim personalitzat durant el registre via el SDK Admin de Firebase.

firebase

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

Opció 4: Contingut públic només-lectura

Per a contingut de màrqueting, perfils públics, catàlegs de productes — qualsevol cosa que sigui genuïnament de lectura pública però d'escriptura només per a administradors. match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }. El claim personalitzat admin s'estableix només en comptes d'administrador.

firebase

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

Consulta d'auditoria ràpida

Abans de corregir, comprova si if true és realment viu. Obre Firebase Console → Firestore → Rules i cerca if true. Si el trobes en qualsevol lloc fora d'un comentari, tens una troballa de regla oberta. El simulador de regles a la mateixa UI et permet reproduir la petició de l'atacant localment — enganxa un GET /users/somebody anònim i confirma que el simulador retorna Allowed.

Confirmació externa: executa un escaneig de FixVibe contra el teu URL de producció. La comprovació baas.firebase-rules sondeja les teves regles de Firestore, Realtime Database i Storage i informa de la mateixa troballa que descobriria un atacant — independentment del que mostri la consola de Firebase.

Preguntes freqüents

Quina és la diferència entre <code>if true</code> i <code>if request.auth != null</code>?

if true permet accés anònim — qualsevol persona a internet. if request.auth != null requereix qualsevol usuari amb sessió iniciada, que és millor però encara és incorrecte: qualsevol usuari de la teva aplicació pot llegir les dades de qualsevol altre usuari. Les regles de producció han de delimitar l'usuari específic o l'organització via request.auth.uid == resource.data.owner_uid o similar.

Caduquen alguna vegada les regles <code>if true</code> automàticament a Firebase?

Els projectes més antics (pre-2023) tenien un temporitzador de 30 dies que convertia les regles if true en if false. Els projectes actuals no — la regla persisteix indefinidament fins que es substitueixi manualment. Si vas crear el teu projecte abans del 2023 i les teves regles semblen correctes, comprova-ho dues vegades: el temporitzador pot haver-les canviat ja a if false, fet que bloqueja la teva pròpia aplicació.

Puc fer servir una comprovació de marca temporal de data futura com a xarxa de seguretat?

No — una condició de marca temporal no és un control de seguretat. Fa caducar la regla oberta en una data futura, fet que vol dir que fins aquella data els atacants tenen accés complet. I tu oblidaràs la data. Substitueix if true per una regla delimitada per autenticació, no per una limitada pel temps.

Què passa si la meva aplicació és genuïnament de lectura pública (blog, catàleg de productes)?

Aleshores escriu explícitament allow read: if true; allow write: if false; només a la col·lecció pública — no a totes les col·leccions de la teva base de dades. Fes servir una clàusula match separada per col·lecció i no facis servir mai el comodí recursiu {document=**} en regles que permetin escriptura.

Següents passos

Executa un escaneig de FixVibe contra el teu URL de producció — la comprovació baas.firebase-rules confirma si if true és actualment explotable des d'internet pública. Per a la mecànica de l'escàner i les deteccions paral·leles per a Realtime Database i Storage, consulta Escàner de regles de Firebase. Per a la classe equivalent de configuració errònia a Supabase, llegeix Escàner de RLS de Supabase.