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

Firebase allow read, write: if true spiegatu: ciò chì face è cumu currighjelu

Q: Chì sfarenza ci hè trà if true è if request.auth != null ?

if true permette accessu anonimu — chìunque in internet. if request.auth != null richiede qualunque utente firmatu, chì hè megliu ma sempre sbagliatu: qualunque utente di a to app pò leghje i dati di ogni altru utente. E regule di produzzione devenu esse limitate à l'utente specificu o à l'urganizazione via request.auth.uid == resource.data.owner_uid o simile.

Q: Ciò chì succede s'è a mio app hè genuinamente di lettura pubblica (blog, cataloghu prudottu)?

Allora scrivi esplicitamente allow read: if true; allow write: if false; nantu à a cullezzione pubblica solu — micca nantu à ogni cullezzione in a to basa di dati. Adopra una clausula match separata per cullezzione è mai aduprà u wildcard ricursivu '{'document=**'}' nantu à regule scrivibili.

<code>allow read, write: if true;</code> hè u sbagliu di cunfigurazione Firebase più cumunu in produzzione. Hè u difettu di test-mode chì a Cunsola Firebase suggerisce quandu crei una nova basa di dati, a regula chì l'attrezzi di codifica IA regeneranu da a documentazione, è a regula chì apre a to basa di dati Firestore sana à chìunque in internet. St'articulu spiega a sintassi precisamente, mostra ciò chì vede un attaccante quandu sta regula hè viva, è ti dà quattru sustituti progressivamente più stretti chì calzanu casi d'usu differenti.

A sintassi, linea per linea

Un documentu di regule Firestore di test-mode cumpletu hè sei linee:

firebase

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

Decodatu:

rules_version = '2'; sceglie u mutore di regule v2 (currente). E regule v1 più vechje sò deprecate.
service cloud.firestore limita u bloccu à Firestore. Realtime Database usa una sintassi diversa basata in JSON; Cloud Storage usa service firebase.storage.
match /databases/{database}/documents liga a basa di dati speziale (default) (a maiò parte di i prughjetti ne anu solu una).
match /{document=**} hè un wildcard ricursivu. U ** matcheghja qualunque percorsu di qualunque profondità. Cumbinatu cù {document}, questu cattura ogni documentu in ogni cullezzione — una sola clausula di match chì guverna a basa di dati sana.
allow read, write: if true; hè u corpu di a regula. Sia read sia write sò permessi; a cundizione if true hè, in fatti, sempre vera. read copre l'operazioni get è list; write copre create, update, è delete.

Effettu nettu: qualunque cliente cù l'ID di prughjettu Firebase è l'SDK ghjustu pò leghje o scrive qualunque documentu in qualunque cullezzione. L'autenticazione ùn hè micca richiesta. I limiti di tassa ùn sò micca imposti.

Perchè Firebase a manda cum'è difettu

Firebase vole chì tù sii à codificà in i primi 30 secondi dopu avè creatu un prughjettu. L'alternativa — fà ti scrive una regula curretta prima chì qualunque lettura o scrittura funziuneghji — bluccherebbe l'onboarding. Cusì a Cunsola offre duie opzioni quandu crei una basa di dati: Production mode (nega tuttu, scrivi tù e regule) o Test mode (permettine tuttu per 30 ghjorni). A maiò parte di i sviluppatori cliccanu test mode, dopu si scordanu di rivisità. I prughjetti più vechji avianu u timer di 30 ghjorni; i prughjetti currenti anu una regula if true indefinita senza scadenza automatica.

U prublema strutturale: l'attrezzi di codifica IA s'addestranu nantu à documentazione, tutoriali è risposte di Stack Overflow chì mostranu regule di test-mode. Quandu dumandi à Cursor o Claude Code "cumu cunfigurà Firebase," a risposta spessu include u bloccu esattu allow read, write: if true cum'è s'ellu era a regula di produzzione. L'IA ùn sà — è ùn hè micca sollecitata à sapè — chì sta regula ùn hè micca sicura per a produzzione.

Ciò chì vede un attaccante

Cuncretamente, un attaccante chì cunnosce u to ID di prughjettu Firebase (estraibile da u bundle di qualunque app spiegata in 30 secondi) è chì gira u seguente pò listà ogni documentu in ogni cullezzione:

Una sola richiesta curl micca autenticata basta per enumerà ogni cullezzione. Vedi u bloccu evidenziatu sottu.

bash

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

A risposta hè a lista cumpleta di e cullezzioni di livellu sopra. Per ogni cullezzione, una seconda richiesta torna documenti. Ùn ci hè micca limitu di tassa nantu à stu percorsu perchè e regule if true accettanu trafficu anonimu. Avemu vistu basa di dati Firebase cù milioni di documenti enumerati in menu d'una ora.

Nantu à u percorsu di scrittura: un sulu POST cù {fields} crea un novu documentu. L'attaccanti ponu pulluì e to cullezzioni cù scempii, deface pagine d'utente chì leghjenu da Firestore, o aduprà a to basa di dati cum'è un mediatore di messaghji gratisi — u to fattura d'usu salta in altu, indaghi, è a fattura spiega u prublema.

Quattru sustituti sicuri per a produzzione

Sceglie u sustitutu chì matcheghja u mudellu di dati di a to app. Tutti i quattru suppongunu chì hai l'autenticazione d'utente (Firebase Auth o qualunque fornitore chì emette un token ID Firebase):

Opzione 1: Documenti pussiduti da l'utente

U pattern SaaS più cumunu. I documenti vivenu sottu à /users/{userId}/... è solu u patrone i pò toccà. 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;
}

Opzione 2: Campu di patrone in ogni documentu

Quandu i documenti vivenu in cullezzioni piate (micca innide sottu à l'ID d'utente), guarda un campu owner_uid è cuntrolla. 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;
}

Opzione 3: Isolamentu multi-tenant per urganizazione

Per SaaS B2B cù dati cu scope per urganizazione. Guarda un campu org_id in ogni documentu è cuntrolla contru à u claim persunalizatu di l'utente. allow read, write: if request.auth.token.org_id == resource.data.org_id;. Richiede di mette u claim persunalizatu durante a registrazione via l'SDK d'amministrazione Firebase.

firebase

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

Opzione 4: Cuntenutu publicu di solu lettura

Per cuntenutu di marketing, prufili publichi, cataloghi di prudottu — qualunque cosa chì hè genuinamente di lettura pubblica ma di scrittura solu per amministratore. match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }. U claim persunalizatu admin hè messu solu nantu à i cunti d'amministratore.

firebase

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

Query d'audit rapida

Prima di curreghje, cuntrolla s'è if true hè veramente vivu. Apri Cunsola Firebase → Firestore → Rules è cerca if true. S'è u trovi in qualunque locu fora di un cumentu, hai un risultatu di regula aperta. U simulatore di regule in listessu UI ti lascia ripiglià a richiesta di l'attaccante in lucale — incolla un anonimu GET /users/somebody è cunferma chì u simulatore torna Allowed.

Cunfirmazione esterna: lampa una scansione FixVibe contru à u to URL di produzzione. U check baas.firebase-rules sonda e to regule Firestore, Realtime Database, è Storage è riporta listessu risultatu chì un attaccante scuprerebbe — indipendentemente da ciò chì mostra a Cunsola Firebase.

Dumande frequenti

Chì sfarenza ci hè trà <code>if true</code> è <code>if request.auth != null</code>?

if true permette accessu anonimu — chìunque in internet. if request.auth != null richiede qualunque utente firmatu, chì hè megliu ma sempre sbagliatu: qualunque utente di a to app pò leghje i dati di ogni altru utente. E regule di produzzione devenu esse limitate à l'utente specificu o à l'urganizazione via request.auth.uid == resource.data.owner_uid o simile.

Firebase scade mai automaticamente e regule <code>if true</code>?

I prughjetti più vechji (pre-2023) avianu un timer di 30 ghjorni chì cunvertia e regule if true in if false. I prughjetti currenti nò — a regula persevera indefinitamente finu à rimpiazzata manualmente. S'è hai creatu u to prughjettu prima di 2023 è e to regule paranu bè, ricuntrolla: u timer pò aver digià invertitule à if false, chì blocca a to propria app.

Possu aduprà un cuntrollu di timestamp di data futura cum'è rete di sicurezza?

Nò — una cundizione di timestamp ùn hè micca un cuntrollu di sicurezza. Scade a regula aperta à una data futura, ciò chì significheghja chì finu à quella data l'attaccanti anu accessu pienu. È ti scurderai a data. Rimpiazza if true cù una regula limitata da auth, micca una limitata da u tempu.

Ciò chì succede s'è a mio app hè genuinamente di lettura pubblica (blog, cataloghu prudottu)?

Allora scrivi esplicitamente allow read: if true; allow write: if false; nantu à a cullezzione pubblica solu — micca nantu à ogni cullezzione in a to basa di dati. Adopra una clausula match separata per cullezzione è mai aduprà u wildcard ricursivu {document=**} nantu à regule scrivibili.

Prussimi passi

Lampa una scansione FixVibe contru à u to URL di produzzione — u check baas.firebase-rules cunferma s'è if true hè attualmente sfruttabile da l'internet publicu. Per i meccanismi di scanner è e rilevazioni parallele per Realtime Database è Storage, vedi Scanner di regule Firebase. Per a classa equivalente di sbagliu di cunfigurazione nantu à Supabase, leghji Scanner RLS Supabase.