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

Firebase allow read, write: if true razloženo: kaj počne in kako ga popraviti

Q: Kakšna je razlika med if true in if request.auth != null ?

if true dovoli anonimen dostop — vsakomur na internetu. if request.auth != null zahteva katerega koli prijavljenega uporabnika, kar je boljše, vendar še vedno narobe: vsak uporabnik vaše aplikacije lahko bere podatke vseh drugih uporabnikov. Produkcijska pravila morajo biti omejena na konkretnega uporabnika ali organizacijo prek request.auth.uid == resource.data.owner_uid ali podobno.

Q: Kaj če je moja aplikacija resnično javno-berljiva (blog, katalog izdelkov)?

Potem izrecno napišite allow read: if true; allow write: if false; samo na javni zbirki — ne na vsaki zbirki v vaši bazi podatkov. Uporabite ločeno match-klavzulo na zbirko in nikoli ne uporabljajte rekurzivnega nadomestila '{'document=**'}' na pravilih za pisanje.

<code>allow read, write: if true;</code> je daleč najpogostejša napačna konfiguracija Firebase v produkciji. To je privzeta vrednost test-načina, ki jo predlaga konzola Firebase, ko ustvarite novo bazo podatkov, pravilo, ki ga UI-orodja za kodiranje znova ustvarjajo iz dokumentacije, in pravilo, ki vašo celotno Firestore-bazo odpre vsakomur na internetu. Ta članek natančno razloži sintakso, pokaže, kaj vidi napadalec, ko je to pravilo aktivno, in vam ponudi štiri progresivno strožje zamenjave za različne primere uporabe.

Sintaksa, vrstico za vrstico

Popoln Firestore-dokument pravil test-načina je šest vrstic dolg:

firebase

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

Dekodirano:

rules_version = '2'; izbere mehanizem pravil v2 (trenutni). Starejša pravila v1 so opuščena.
service cloud.firestore omeji blok na Firestore. Realtime Database uporablja drugo sintakso, osnovano na JSON; Cloud Storage uporablja service firebase.storage.
match /databases/{database}/documents veže posebno bazo podatkov (default) (večina projektov ima samo eno).
match /{document=**} je rekurzivni nadomestilni znak. ** se ujema s katero koli potjo katere koli globine. V kombinaciji z {document} to ujame vsak dokument v vsaki zbirki — ena sama match-klavzula, ki vlada celotni bazi podatkov.
allow read, write: if true; je telo pravila. Dovoljena sta tako read kot write; pogoj if true je pač vedno resničen. read pokriva operaciji get in list; write pokriva create, update in delete.

Neto učinek: kateri koli odjemalec z ID-jem Firebase-projekta in pravim SDK-jem lahko bere ali piše kateri koli dokument v kateri koli zbirki. Avtentikacija ni potrebna. Omejitve hitrosti se ne uveljavljajo.

Zakaj Firebase to izdaja kot privzeto

Firebase želi, da kodirate v prvih 30 sekundah po ustvarjanju projekta. Alternativa — da bi vas prisilil, da pred vsakim branjem ali pisanjem napišete pravilno pravilo — bi blokirala prijavo. Zato konzola ob ustvarjanju baze podatkov ponudi dve možnosti: Production mode (vse zavrni, pravila napišete vi) ali Test mode (vse dovoli za 30 dni). Večina razvijalcev klikne test mode in nato pozabi to ponovno preveriti. Starejši projekti so imeli 30-dnevni časovnik; trenutni projekti imajo nedoločeno pravilo if true brez samodejnega poteka.

Strukturna težava: UI-orodja za kodiranje se učijo na dokumentaciji, tutorialih in odgovorih Stack Overflow, ki prikazujejo pravila test-načina. Ko Cursorja ali Claude Code vprašate „kako postavim Firebase", odgovor pogosto vključuje natančen blok allow read, write: if true, kot da je to produkcijsko pravilo. UI ne ve — in ni pozvan, da bi vedel — da to pravilo ni varno za produkcijo.

Kaj vidi napadalec

Konkretno: napadalec, ki pozna vaš ID Firebase-projekta (izvlečen iz snopa katere koli izdane aplikacije v 30 sekundah) in zažene naslednje, lahko izpiše vsak dokument v vsaki zbirki:

Ena sama nepristna zahteva curl je dovolj za naštevanje vsake zbirke. Glejte označen blok spodaj.

bash

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

Odziv je popoln seznam zbirk najvišje ravni. Za vsako zbirko druga zahteva vrne dokumente. Na tej poti ni omejitev hitrosti, ker pravila if true sprejmejo anonimen promet. Videli smo Firebase-baze z milijoni dokumentov, ki so bili našteti v manj kot eni uri.

Na pisalni poti: en sam POST z {fields} ustvari nov dokument. Napadalci lahko vaše zbirke onesnažijo z navlako, oskrunijo uporabniške strani, ki berejo iz Firestore, ali vašo bazo podatkov uporabijo kot brezplačnega posrednika sporočil — vaš račun za uporabo poskoči, vi raziščete, račun pojasni problem.

Štiri produkcijsko varne zamenjave

Izberite zamenjavo, ki se ujema s podatkovnim modelom vaše aplikacije. Vse štiri predpostavljajo, da imate uporabniško avtentikacijo (Firebase Auth ali kateri koli ponudnik, ki izda Firebase ID-žeton):

Možnost 1: Uporabniško lastni dokumenti

Najpogostejši vzorec SaaS. Dokumenti živijo pod /users/{userId}/... in se jih lahko dotakne samo lastnik. 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;
}

Možnost 2: Polje lastnika na vsakem dokumentu

Kadar dokumenti živijo v ploskih zbirkah (ne ugnezdeni pod uporabniško ID), shranite polje owner_uid in ga preverite. 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;
}

Možnost 3: Večnajemniška izolacija organizacij

Za B2B SaaS s podatki, omejenimi po organizaciji. Shranite polje org_id na vsakem dokumentu in ga preverite proti uporabnikovemu lastnemu zahtevku. allow read, write: if request.auth.token.org_id == resource.data.org_id;. Zahteva nastavitev lastnega zahtevka med registracijo prek Firebase Admin SDK.

firebase

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

Možnost 4: Vsebina samo za branje, javna

Za marketinško vsebino, javne profile, kataloge izdelkov — vse, kar je resnično javno za branje, vendar samo za skrbnike za pisanje. match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }. Lastni zahtevek admin se nastavi le na skrbniških računih.

firebase

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

Hitra poizvedba za pregled

Preden popravljate, preverite, ali je if true dejansko aktiven. Odprite konzolo Firebase → Firestore → Rules in poiščite if true. Če ga najdete kjer koli zunaj komentarja, imate najdbo odprtega pravila. Simulator pravil v isti uporabniški vmesnik vam omogoča lokalno reprodukcijo napadalčeve zahteve — prilepite anonimen GET /users/somebody in potrdite, da simulator vrne Allowed.

Zunanja potrditev: zaženite FixVibe-pregled proti svojemu produkcijskemu URL-ju. Pregled baas.firebase-rules sondira vaša pravila Firestore, Realtime Database in Storage ter sporoči isto najdbo, ki bi jo odkril napadalec — neodvisno od tega, kar prikazuje konzola Firebase.

Pogosto zastavljena vprašanja

Kakšna je razlika med <code>if true</code> in <code>if request.auth != null</code>?

if true dovoli anonimen dostop — vsakomur na internetu. if request.auth != null zahteva katerega koli prijavljenega uporabnika, kar je boljše, vendar še vedno narobe: vsak uporabnik vaše aplikacije lahko bere podatke vseh drugih uporabnikov. Produkcijska pravila morajo biti omejena na konkretnega uporabnika ali organizacijo prek request.auth.uid == resource.data.owner_uid ali podobno.

Ali Firebase kdaj samodejno razveljavi pravila <code>if true</code>?

Starejši projekti (pred 2023) so imeli 30-dnevni časovnik, ki je pravila if true pretvoril v if false. Trenutni projekti ne — pravilo vztraja nedoločeno dolgo, dokler ga ne nadomestite ročno. Če ste svoj projekt ustvarili pred 2023 in vaša pravila izgledajo v redu, dvakrat preverite: časovnik jih je morda že prevrnil v if false, kar blokira vašo lastno aplikacijo.

Ali lahko kot varovalno mrežo uporabim preverjanje časovnega žiga s prihodnjim datumom?

Ne — pogoj časovnega žiga ni varnostni nadzor. Pravilo poteče na prihodnji datum, kar pomeni, da imajo napadalci do tega datuma poln dostop. In datum boste pozabili. if true zamenjajte s pravilom, omejenim z avtentikacijo, ne časovno.

Kaj če je moja aplikacija resnično javno-berljiva (blog, katalog izdelkov)?

Potem izrecno napišite allow read: if true; allow write: if false; samo na javni zbirki — ne na vsaki zbirki v vaši bazi podatkov. Uporabite ločeno match-klavzulo na zbirko in nikoli ne uporabljajte rekurzivnega nadomestila {document=**} na pravilih za pisanje.

Naslednji koraki

Zaženite FixVibe-pregled proti svojemu produkcijskemu URL-ju — pregled baas.firebase-rules potrdi, ali je if true trenutno izkoristljiv iz javnega interneta. Za mehaniko skenerja in vzporedne zaznave za Realtime Database in Storage glejte Skener pravil Firebase. Za enakovreden razred napačne konfiguracije pri Supabase preberite Skener Supabase RLS.