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

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

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

if true dozvoljava anonimni 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: Šta 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 — 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 kreirate 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 šta napadač vidi kada je ovo pravilo aktivno i daje vam četiri sve strožije zamjene koje odgovaraju različitim slučajevima upotrebe.

Sintaksa, red po red

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 zasnovanu 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 dozvoljeni; uslov if true je, pa, uvijek istinit. read pokriva operacije get i list; write pokriva create, update i delete.

Neto efekat: 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 kreiranja 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 kreirate bazu: Production mode (zabrani sve, vi pišete pravila) ili Test mode (dozvoli sve 30 dana). Većina developera klikne test mode, pa zaboravi da se vrati. 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 tačan blok allow read, write: if true kao da je to produkcijsko pravilo. AI ne zna — i nije podstaknut da zna — da ovo pravilo nije sigurno za produkciju.

Šta 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 kompletna lista kolekcija najvišeg nivoa. Za svaku kolekciju, drugi zahtjev vraća dokumente. Na ovoj putanji nema ograničenja brzine jer pravila if true prihvataju anonimni saobraćaj. Vidjeli smo Firebase baze s milionima dokumenata nabrojanih u manje od sat vremena.

Na putu pisanja: jedan POST s {fields} kreira 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), sačuvajte 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 sa podacima ograničenim po organizaciji. Sačuvajte 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 tokom 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ćava vam ponovno reprodukovanje napadačevog zahtjeva lokalno — zalijepite anonimni GET /users/somebody i potvrdite da simulator vraća Allowed.

Eksterna 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 — nezavisno od onoga š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 dozvoljava anonimni 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 konvertovao if true pravila u if false. Trenutni projekti nemaju — pravilo opstaje neograničeno dok se ručno ne zamijeni. Ako ste kreirali projekat 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 — uslov 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, ne onim ograničenim vremenom.

Šta 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 — 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.