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

Firebase allow read, write: if true objašnjeno: što to radi i kako popraviti

Q: Koja je razlika između if true i if request.auth != null ?

if true dopušta anoniman pristup — svakome na internetu. if request.auth != null zahtijeva bilo kojeg prijavljenog korisnika, što je bolje ali još uvijek pogrešno: bilo koji korisnik vaše aplikacije može čitati podatke svakog drugog korisnika. Produkcijska pravila moraju se ograničiti na konkretnog korisnika ili organizaciju preko request.auth.uid == resource.data.owner_uid ili sličnog.

Q: Što ako je moja aplikacija zaista javno-čitljiva (blog, katalog proizvoda)?

Onda eksplicitno napišite allow read: if true; allow write: if false; samo na javnoj kolekciji — a ne na svakoj kolekciji u svojoj bazi. Koristite zasebnu match klauzulu po kolekciji i nikada ne koristite rekurzivni wildcard '{'document=**'}' na pravilima koja se mogu pisati.

<code>allow read, write: if true;</code> je najčešća pojedinačna pogrešna konfiguracija Firebasea u produkciji. To je default test-modea koji Firebase konzola predlaže kada stvarate novu bazu, pravilo koje AI alati za kodiranje regeneriraju iz dokumentacije i pravilo koje otvara cijelu vašu Firestore bazu svima na internetu. Ovaj članak precizno objašnjava sintaksu, pokazuje što napadač vidi kada je ovo pravilo aktivno i daje vam četiri sve strože zamjene koje odgovaraju različitim slučajevima upotrebe.

Sintaksa, redak po redak

Kompletan Firestore test-mode dokument pravila ima šest linija:

firebase

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

Dekodirano:

rules_version = '2'; bira v2 rules engine (trenutni). Starija v1 pravila su zastarjela.
service cloud.firestore ograničava blok na Firestore. Realtime Database koristi drugačiju sintaksu temeljenu na JSON-u; Cloud Storage koristi service firebase.storage.
match /databases/{database}/documents vezuje posebnu (default) bazu (većina projekata ima samo jednu).
match /{document=**} je rekurzivni wildcard. ** odgovara bilo kojoj putanji bilo koje dubine. U kombinaciji s {document}, ovo hvata svaki dokument u svakoj kolekciji — jedna match klauzula koja upravlja cijelom bazom.
allow read, write: if true; je tijelo pravila. I read i write su dopušteni; uvjet if true je, pa, uvijek istinit. read pokriva operacije get i list; write pokriva create, update i delete.

Neto učinak: bilo koji klijent s Firebase project ID-jem i odgovarajućim SDK-om može čitati ili pisati bilo koji dokument u bilo kojoj kolekciji. Autentifikacija nije potrebna. Ograničenja brzine ne primjenjuju se.

Zašto Firebase ovo isporučuje kao default

Firebase želi da kodirate u prvih 30 sekundi nakon stvaranja projekta. Alternativa — natjerati vas da napišete ispravno pravilo prije nego što bilo koje čitanje ili pisanje proradi — blokirala bi onboarding. Tako konzola nudi dvije opcije kada stvarate bazu: Production mode (zabrani sve, vi pišete pravila) ili Test mode (dopusti sve 30 dana). Većina developera klikne test mode, pa zaboravi vratiti se. Stariji projekti imali su 30-dnevni tajmer; trenutni projekti imaju neodređeno if true pravilo bez automatskog isteka.

Strukturni problem: AI alati za kodiranje treniraju na dokumentaciji, tutorijalima i Stack Overflow odgovorima koji pokazuju test-mode pravila. Kada pitate Cursor ili Claude Code "kako da postavim Firebase", odgovor često uključuje točan blok allow read, write: if true kao da je to produkcijsko pravilo. AI ne zna — i nije potaknut da zna — da ovo pravilo nije sigurno za produkciju.

Što napadač vidi

Konkretno, napadač koji zna vaš Firebase project ID (može se izvući iz bundlea bilo koje deploy-ane aplikacije za 30 sekundi) i pokrene sljedeće može izlistati svaki dokument u svakoj kolekciji:

Jedan neautenticirani curl zahtjev dovoljan je za nabrajanje svake kolekcije. Vidi istaknuti blok ispod.

bash

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

Odgovor je kompletan popis kolekcija najviše razine. Za svaku kolekciju, drugi zahtjev vraća dokumente. Na ovoj putanji nema ograničenja brzine jer pravila if true prihvaćaju anonimni promet. Vidjeli smo Firebase baze s milijunima dokumenata nabrojanih u manje od sata.

Na putu pisanja: jedan POST s {fields} stvara novi dokument. Napadači mogu zagaditi vaše kolekcije smećem, defejsirati stranice za korisnike koje čitaju iz Firestorea ili koristiti vašu bazu kao besplatan posrednik za poruke — vaš račun za upotrebu skače, istražujete, račun objašnjava problem.

Četiri produkcijski sigurne zamjene

Odaberite zamjenu koja odgovara modelu podataka vaše aplikacije. Sve četiri pretpostavljaju da imate korisničku autentifikaciju (Firebase Auth ili bilo koji provider koji izdaje Firebase ID token):

Opcija 1: Dokumenti u vlasništvu korisnika

Najčešći SaaS obrazac. Dokumenti žive pod /users/{userId}/... i samo vlasnik ih može dirati. 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;
}

Opcija 2: Polje vlasnika na svakom dokumentu

Kada dokumenti žive u plitkim kolekcijama (ne ugniježđeni pod korisničkim ID-jem), pohranite polje owner_uid i provjerite ga. 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;
}

Opcija 3: Multi-tenant izolacija organizacija

Za B2B SaaS s podacima ograničenim po organizaciji. Pohranite polje org_id na svakom dokumentu i provjerite ga u odnosu na korisnikov custom claim. allow read, write: if request.auth.token.org_id == resource.data.org_id;. Zahtijeva postavljanje custom claima tijekom registracije preko Firebase Admin SDK-a.

firebase

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

Opcija 4: Read-only javni sadržaj

Za marketinški sadržaj, javne profile, kataloge proizvoda — sve što je istinski javno-čitljivo, ali samo admin-pisivo. match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }. Custom claim admin postavljen je samo na admin računima.

firebase

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

Brz audit upit

Prije popravka, provjerite je li if true zaista aktivno. Otvorite Firebase konzolu → Firestore → Rules i potražite if true. Ako ga pronađete bilo gdje izvan komentara, imate nalaz otvorenog pravila. Simulator pravila u istom UI-ju omogućuje vam ponovno reprodukciju napadačevog zahtjeva lokalno — zalijepite anoniman GET /users/somebody i potvrdite da simulator vraća Allowed.

Vanjska potvrda: pokrenite FixVibe sken prema svom produkcijskom URL-u. Provjera baas.firebase-rules ispituje vaša Firestore, Realtime Database i Storage pravila i prijavljuje isti nalaz koji bi napadač otkrio — neovisno o onome što Firebase konzola pokazuje.

Često postavljana pitanja

Koja je razlika između <code>if true</code> i <code>if request.auth != null</code>?

if true dopušta anoniman pristup — svakome na internetu. if request.auth != null zahtijeva bilo kojeg prijavljenog korisnika, što je bolje ali još uvijek pogrešno: bilo koji korisnik vaše aplikacije može čitati podatke svakog drugog korisnika. Produkcijska pravila moraju se ograničiti na konkretnog korisnika ili organizaciju preko request.auth.uid == resource.data.owner_uid ili sličnog.

Da li Firebase ikad automatski istječe <code>if true</code> pravila?

Stariji projekti (prije 2023.) imali su 30-dnevni tajmer koji je konvertirao if true pravila u if false. Trenutni projekti nemaju — pravilo opstaje neograničeno dok se ručno ne zamijeni. Ako ste stvorili projekt prije 2023. i pravila vam izgledaju u redu, dvaput provjerite: tajmer ih je možda već prebacio na if false, što blokira vašu vlastitu aplikaciju.

Mogu li koristiti provjeru timestampa u budućnosti kao sigurnosnu mrežu?

Ne — uvjet timestampa nije sigurnosna kontrola. Otvara pravilo istječe na budući datum, što znači da do tog datuma napadači imaju pun pristup. A vi ćete zaboraviti datum. Zamijenite if true pravilom ograničenim na autentifikaciju, a ne onim ograničenim vremenom.

Što ako je moja aplikacija zaista javno-čitljiva (blog, katalog proizvoda)?

Onda eksplicitno napišite allow read: if true; allow write: if false; samo na javnoj kolekciji — a ne na svakoj kolekciji u svojoj bazi. Koristite zasebnu match klauzulu po kolekciji i nikada ne koristite rekurzivni wildcard {document=**} na pravilima koja se mogu pisati.

Sljedeći koraci

Pokrenite FixVibe sken prema svom produkcijskom URL-u — provjera baas.firebase-rules potvrđuje je li if true trenutno iskoristivo s javnog interneta. Za mehaniku skenera i paralelne detekcije za Realtime Database i Storage, pogledajte Skener Firebase pravila. Za ekvivalentnu klasu pogrešnih konfiguracija na Supabaseu, pročitajte Supabase RLS skener.