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

Firebase allow read, write: if true selgitatud: mida see teeb ja kuidas seda parandada

Q: Mis on erinevus if true ja if request.auth != null vahel?

if true lubab anonüümset juurdepääsu — kõigile internetis. if request.auth != null nõuab mis tahes sissekirjutanud kasutajat, mis on parem, aga ikkagi vale: iga sinu rakenduse kasutaja saab lugeda iga teise kasutaja andmeid. Tootmisreeglid peavad piirduma konkreetse kasutaja või orgiga, kasutades näiteks request.auth.uid == resource.data.owner_uid.

Q: Mis siis, kui mu rakendus on tõeliselt avalikult loetav (blogi, tootekataloog)?

Siis kirjuta selgesõnaliselt allow read: if true; allow write: if false; ainult avalikule kollektsioonile — mitte igale kollektsioonile oma andmebaasis. Kasuta kollektsiooni kohta eraldi match-klauslit ja ära kunagi kasuta rekursiivset '{'document=**'}'-metasümbolit kirjutatavates reeglites.

<code>allow read, write: if true;</code> on ainus kõige levinum Firebase väärseadistus tootmises. See on test-mode'i vaikeväärtus, mida Firebase Console soovitab uue andmebaasi loomisel, reegel, mida AI-koodimistööriistad dokumentatsioonist regenereerivad, ja reegel, mis avab kogu sinu Firestore andmebaasi kõikidele internetis. See artikkel selgitab süntaksit täpselt, näitab, mida ründaja näeb, kui see reegel on elavas töös, ja annab sulle neli järkjärgult rangemat asendust, mis sobivad erinevatele kasutusjuhtudele.

Süntaks, rida realt

Täielik Firestore test-mode'i reeglite dokument on kuus rida:

firebase

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

Dekodeeritud:

rules_version = '2'; valib v2 reeglimootori (praegune). Vanemad v1 reeglid on aegunud.
service cloud.firestore piirab ploki Firestore'iga. Realtime Database kasutab teistsugust JSON-põhist süntaksit; Cloud Storage kasutab service firebase.storage.
match /databases/{database}/documents seob spetsiaalse (default)-andmebaasi (enamikul projektidel on ainult üks).
match /{document=**} on rekursiivne metasümbol. ** vastab mis tahes raja mis tahes sügavusel. Koos {document}-iga jäädvustab see iga dokumendi igas kollektsioonis — üksainus match-klausel, mis valitseb kogu andmebaasi.
allow read, write: if true; on reegli keha. Nii read kui ka write on lubatud; tingimus if true on, noh, alati tõene. read katab get- ja list-operatsioone; write katab create, update ja delete.

Netomõju: iga klient, kellel on Firebase'i projekti ID ja õige SDK, saab lugeda või kirjutada mis tahes dokumenti mis tahes kollektsioonis. Autentimist ei nõuta. Kiiruspiiranguid ei jõustata.

Miks Firebase tarnib selle vaikeväärtusena

Firebase tahab, et sa koodiksid esimese 30 sekundi jooksul pärast projekti loomist. Alternatiiv — sundida sind kirjutama õige reegel enne kui ükski lugemine või kirjutamine toimib — blokeeriks sisseelamise. Seega pakub Console andmebaasi luues kahte valikut: Production mode (keela kõik, sina kirjutad reeglid) või Test mode (luba 30 päevaks kõik). Enamik arendajaid klõpsab test mode'i ja unustab siis tagasi vaadata. Vanematel projektidel oli 30-päevane taimer; praegustel projektidel on määramatu if true-reegel ilma automaatse aegumiseta.

Struktuurne probleem: AI-koodimistööriistad treenivad dokumentatsioonil, õpetustel ja Stack Overflow vastustel, mis näitavad test-mode'i reegleid. Kui sa palud Cursorilt või Claude Code'ilt "kuidas ma seadistan Firebase'i", sisaldab vastus sageli täpselt allow read, write: if true-plokki nagu oleks see tootmisreegel. AI ei tea — ega teda ei manitseta teadma —, et see reegel pole tootmiseks turvaline.

Mida ründaja näeb

Konkreetselt — ründaja, kes teab sinu Firebase'i projekti ID (eraldatav iga juurutatud rakenduse pakist 30 sekundiga) ja käivitab järgneva, saab loetleda iga dokumendi igas kollektsioonis:

Üksainus autentimata curl-päring on piisav, et loendada iga kollektsioon. Vaata esiletõstetud plokki allpool.

bash

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

Vastus on täielik nimekiri ülataseme kollektsioonidest. Iga kollektsiooni jaoks tagastab teine päring dokumendid. Sellel rajal puudub kiiruspiirang, sest if true-reeglid aktsepteerivad anonüümset liiklust. Oleme näinud Firebase'i andmebaase, kus miljoneid dokumente loendatakse vähem kui tunnis.

Kirjutusrajal: üksainus POST koos {fields}-iga loob uue dokumendi. Ründajad saavad reostada sinu kollektsioone prügiga, vandalismi teha kasutajatele suunatud lehti, mis Firestorest loevad, või kasutada sinu andmebaasi tasuta sõnumibrokeri'na — sinu kasutusarve hüppab, sa uurid asja, arve seletab probleemi.

Neli tootmiseks turvalist asendust

Vali asendus, mis vastab sinu rakenduse andmemudelile. Kõik neli eeldavad, et sul on kasutaja autentimine (Firebase Auth või iga pakkuja, mis Firebase'i ID-tokenit väljastab):

Variant 1: Kasutajale kuuluvad dokumendid

Kõige tavalisem SaaS-i muster. Dokumendid elavad raja /users/{userId}/... all ja ainult omanik saab neid puudutada. 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;
}

Variant 2: Omaniku väli igas dokumendis

Kui dokumendid elavad lameda kollektsioonidena (mitte kasutaja-ID alla pesastatuna), salvesta owner_uid-väli ja kontrolli seda. 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;
}

Variant 3: Mitmerentsükliline org-isolatsioon

B2B-SaaS-ile, kus andmed on org-piiritletud. Salvesta igas dokumendis org_id-väli ja kontrolli seda kasutaja kohandatud väite vastu. allow read, write: if request.auth.token.org_id == resource.data.org_id;. Nõuab kohandatud väite seadmist registreerimise ajal Firebase Admin SDK kaudu.

firebase

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

Variant 4: Ainult-lugemiseks avalik sisu

Turundussisule, avalikele profiilidele, tootekataloogidele — kõigele, mis on tõeliselt avalikult loetav, kuid ainult administraatori poolt kirjutatav. match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }. admin-kohandatud väide määratakse ainult administraatori kontodele.

firebase

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

Kiire auditeerimispäring

Enne parandamist kontrolli, kas if true on tegelikult elavas töös. Ava Firebase Console → Firestore → Rules ja otsi if true-i. Kui leiad selle kuskil väljaspool kommentaari, on sul avatud reegli leid. Sama UI Rules simulaator laseb sul ründaja päringut kohapeal mängida — kleebi anonüümne GET /users/somebody ja kinnita, et simulaator tagastab Allowed.

Väline kinnitus: käivita FixVibe-skannimine oma tootmise URL-i vastu. Kontroll baas.firebase-rules sondeerib sinu Firestore, Realtime Database ja Storage reegleid ning teatab samast leiust, mille ründaja avastaks — sõltumata sellest, mida Firebase Console näitab.

Korduma kippuvad küsimused

Mis on erinevus <code>if true</code> ja <code>if request.auth != null</code> vahel?

if true lubab anonüümset juurdepääsu — kõigile internetis. if request.auth != null nõuab mis tahes sissekirjutanud kasutajat, mis on parem, aga ikkagi vale: iga sinu rakenduse kasutaja saab lugeda iga teise kasutaja andmeid. Tootmisreeglid peavad piirduma konkreetse kasutaja või orgiga, kasutades näiteks request.auth.uid == resource.data.owner_uid.

Kas Firebase aegestab <code>if true</code>-reeglid kunagi automaatselt?

Vanematel projektidel (enne 2023) oli 30-päevane taimer, mis muutis if true-reeglid if false-iks. Praegustel projektidel pole — reegel püsib määramatult, kuni see käsitsi asendatakse. Kui lõid projekti enne 2023. aastat ja sinu reeglid näevad korrektsed välja, kontrolli kaks korda: taimer võis nad juba if false-iks pööranda, mis blokeerib su enda rakenduse.

Kas ma saan kasutada tuleviku-kuupäeva ajatempli kontrolli turvavõrguna?

Ei — ajatempli tingimus ei ole turvakontroll. See aegestab avatud reegli tuleviku-kuupäeval, mis tähendab, et selle kuupäevani on ründajatel täielik juurdepääs. Ja sa unustad kuupäeva. Asenda if true auth-piiratud reegliga, mitte ajalimitseeritud reegliga.

Mis siis, kui mu rakendus on tõeliselt avalikult loetav (blogi, tootekataloog)?

Siis kirjuta selgesõnaliselt allow read: if true; allow write: if false; ainult avalikule kollektsioonile — mitte igale kollektsioonile oma andmebaasis. Kasuta kollektsiooni kohta eraldi match-klauslit ja ära kunagi kasuta rekursiivset {document=**}-metasümbolit kirjutatavates reeglites.

Järgmised sammud

Käivita FixVibe-skannimine oma tootmise URL-i vastu — kontroll baas.firebase-rules kinnitab, kas if true on praegu avalikust internetist ärakasutatav. Skanneri mehaanika ja paralleelse Realtime Database ja Storage tuvastamise jaoks vaata Firebase reeglite skanner. Sama väärseadistuste klassi jaoks Supabases loe Supabase RLS-skanner.