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

Firebase allow read, write: if true explicat: ce face și cum se remediază

Q: Care este diferența dintre if true și if request.auth != null ?

if true permite acces anonim — oricine pe internet. if request.auth != null necesită orice utilizator conectat, ceea ce este mai bine, dar tot greșit: orice utilizator al aplicației tale poate citi datele oricărui alt utilizator. Regulile de producție trebuie delimitate la utilizatorul specific sau la organizație prin request.auth.uid == resource.data.owner_uid sau similar.

Q: Ce dacă aplicația mea este cu adevărat public-readable (blog, catalog de produse)?

Atunci scrie explicit allow read: if true; allow write: if false; doar pe colecția publică — nu pe fiecare colecție din baza ta de date. Folosește o clauză match separată pe colecție și niciodată nu folosi wildcard-ul recursiv '{'document=**'}' pe reguli scriibile.

<code>allow read, write: if true;</code> este singura cea mai comună configurație greșită Firebase în producție. Este implicitul modului test pe care Firebase Console îl sugerează când creezi o bază de date nouă, regula pe care instrumentele de codare AI o regenerează din documentație și regula care deschide întreaga ta bază de date Firestore oricui de pe internet. Acest articol explică sintaxa cu precizie, arată ce vede un atacator când această regulă este live și îți oferă patru înlocuiri progresiv mai stricte care se potrivesc cu diferite cazuri de utilizare.

Sintaxa, linie cu linie

Un document complet de reguli Firestore în mod test are șase linii:

firebase

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

Decodat:

rules_version = '2'; selectează motorul de reguli v2 (curent). Regulile v1 mai vechi sunt depreciate.
service cloud.firestore delimitează blocul la Firestore. Realtime Database folosește o sintaxă diferită bazată pe JSON; Cloud Storage folosește service firebase.storage.
match /databases/{database}/documents leagă baza de date specială (default) (majoritatea proiectelor au doar una).
match /{document=**} este un wildcard recursiv. ** se potrivește cu orice cale de orice adâncime. Combinat cu {document}, capturează fiecare document din fiecare colecție — o singură clauză match care guvernează întreaga bază de date.
allow read, write: if true; este corpul regulii. Atât read cât și write sunt permise; condiția if true este, ei bine, mereu adevărată. read acoperă operațiunile get și list; write acoperă create, update și delete.

Efect net: orice client cu ID-ul proiectului Firebase și SDK-ul potrivit poate citi sau scrie orice document în orice colecție. Autentificarea nu este necesară. Limitele de rată nu sunt impuse.

De ce livrează Firebase asta ca implicit

Firebase vrea să codezi în primele 30 de secunde după crearea unui proiect. Alternativa — să te facă să scrii o regulă corectă înainte ca orice citire sau scriere să funcționeze — ar bloca onboarding-ul. Așa că Console oferă două opțiuni când creezi o bază de date: Production mode (refuză totul, tu scrii regulile) sau Test mode (permite totul timp de 30 de zile). Majoritatea dezvoltatorilor fac clic pe modul test, apoi uită să revină. Proiectele mai vechi aveau timer-ul de 30 de zile; proiectele curente au o regulă if true nedefinită fără expirare automată.

Problema structurală: instrumentele de codare AI se antrenează pe documentație, tutoriale și răspunsuri Stack Overflow care arată reguli în mod test. Când îi ceri lui Cursor sau Claude Code „cum configurez Firebase", răspunsul include adesea blocul exact allow read, write: if true ca și cum ar fi regula de producție. AI-ul nu știe — și nici nu i se cere să știe — că această regulă nu este sigură pentru producție.

Ce vede un atacator

Concret, un atacator care îți știe ID-ul proiectului Firebase (extractabil din bundle-ul oricărei aplicații deployate în 30 de secunde) și rulează următoarele poate lista fiecare document din fiecare colecție:

O singură cerere curl neautentificată este suficientă pentru a enumera fiecare colecție. Vezi blocul evidențiat mai jos.

bash

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

Răspunsul este lista completă a colecțiilor de nivel superior. Pentru fiecare colecție, o a doua cerere returnează documente. Nu există limită de rată pe această cale, deoarece regulile if true acceptă trafic anonim. Am văzut baze de date Firebase cu milioane de documente enumerate în mai puțin de o oră.

Pe calea de scriere: un singur POST cu {fields} creează un document nou. Atacatorii pot polua colecțiile cu gunoi, defăima paginile orientate spre utilizatori care citesc din Firestore sau folosi baza ta de date ca broker de mesaje gratuit — factura ta de utilizare crește brusc, investighezi, factura explică problema.

Patru înlocuiri sigure pentru producție

Alege înlocuirea care se potrivește cu modelul de date al aplicației tale. Toate cele patru presupun că ai autentificare a utilizatorilor (Firebase Auth sau orice furnizor care emite un Firebase ID token):

Opțiunea 1: documente deținute de utilizatori

Cel mai comun tipar SaaS. Documentele trăiesc sub /users/{userId}/... și doar proprietarul le poate atinge. 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;
}

Opțiunea 2: câmp proprietar pe fiecare document

Când documentele trăiesc în colecții plate (nu cuibărite sub ID-ul utilizatorului), stochează un câmp owner_uid și verifică-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;
}

Opțiunea 3: izolare org multi-tenant

Pentru SaaS B2B cu date delimitate pe org. Stochează un câmp org_id pe fiecare document și verifică-l împotriva claim-ului personalizat al utilizatorului. allow read, write: if request.auth.token.org_id == resource.data.org_id;. Necesită setarea claim-ului personalizat în timpul înregistrării prin Firebase Admin SDK.

firebase

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

Opțiunea 4: conținut public numai-citire

Pentru conținut de marketing, profiluri publice, cataloage de produse — orice este cu adevărat public-readable, dar admin-only-write. match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }. Claim-ul personalizat admin este setat doar pe conturile admin.

firebase

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

Interogare rapidă de audit

Înainte de remediere, verifică dacă if true este de fapt live. Deschide Firebase Console → Firestore → Rules și caută if true. Dacă o găsești undeva în afara unui comentariu, ai un rezultat de regulă deschisă. Simulatorul Rules din aceeași UI îți permite să reiei local cererea atacatorului — lipește un GET /users/somebody anonim și confirmă că simulatorul returnează Allowed.

Confirmare externă: rulează o scanare FixVibe împotriva URL-ului tău de producție. Verificarea baas.firebase-rules sondează regulile tale Firestore, Realtime Database și Storage și raportează același rezultat pe care l-ar descoperi un atacator — independent de ceea ce arată Firebase Console.

Întrebări frecvente

Care este diferența dintre <code>if true</code> și <code>if request.auth != null</code>?

if true permite acces anonim — oricine pe internet. if request.auth != null necesită orice utilizator conectat, ceea ce este mai bine, dar tot greșit: orice utilizator al aplicației tale poate citi datele oricărui alt utilizator. Regulile de producție trebuie delimitate la utilizatorul specific sau la organizație prin request.auth.uid == resource.data.owner_uid sau similar.

Expiră Firebase vreodată automat regulile <code>if true</code>?

Proiectele mai vechi (pre-2023) aveau un timer de 30 de zile care converta regulile if true în if false. Proiectele curente nu — regula persistă pe termen nedefinit până la înlocuirea manuală. Dacă ți-ai creat proiectul înainte de 2023 și regulile tale arată bine, verifică din nou: timer-ul s-ar putea să le fi întors deja la if false, ceea ce blochează propria ta aplicație.

Pot folosi o verificare cu marcaj temporal viitor ca plasă de siguranță?

Nu — o condiție cu marcaj temporal nu este un control de securitate. Expiră regula deschisă la o dată viitoare, ceea ce înseamnă că până la acea dată atacatorii au acces complet. Și vei uita data. Înlocuiește if true cu o regulă delimitată la autentificare, nu cu una limitată în timp.

Ce dacă aplicația mea este cu adevărat public-readable (blog, catalog de produse)?

Atunci scrie explicit allow read: if true; allow write: if false; doar pe colecția publică — nu pe fiecare colecție din baza ta de date. Folosește o clauză match separată pe colecție și niciodată nu folosi wildcard-ul recursiv {document=**} pe reguli scriibile.

Pași următori

Rulează o scanare FixVibe împotriva URL-ului tău de producție — verificarea baas.firebase-rules confirmă dacă if true este în prezent exploatabil de pe internetul public. Pentru mecanica scanerului și detectările paralele pentru Realtime Database și Storage, vezi Scaner de reguli Firebase. Pentru clasa echivalentă de configurare greșită pe Supabase, citește Scaner RLS Supabase.