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

Firebase allow read, write: if true vysvetlené: čo robí a ako to opraviť

Q: Aký je rozdiel medzi if true a if request.auth != null ?

if true povoľuje anonymný prístup — komukoľvek na internete. if request.auth != null vyžaduje akéhokoľvek prihláseného používateľa, čo je lepšie, ale stále nesprávne: akýkoľvek používateľ vašej aplikácie môže čítať dáta každého iného používateľa. Produkčné pravidlá musia byť obmedzené na konkrétneho používateľa alebo organizáciu cez request.auth.uid == resource.data.owner_uid alebo podobné.

Q: Čo ak je moja aplikácia skutočne verejne čitateľná (blog, katalóg produktov)?

Potom explicitne napíšte allow read: if true; allow write: if false; iba na verejnej kolekcii — nie na každej kolekcii vo vašej databáze. Použite samostatnú klauzulu match na kolekciu a nikdy nepoužívajte rekurzívny žolík '{'document=**'}' na zapisovateľných pravidlách.

<code>allow read, write: if true;</code> je jediná najčastejšia chybná konfigurácia Firebase v produkcii. Je to predvolené nastavenie testovacieho režimu, ktoré Firebase Konzola navrhuje, keď vytvoríte novú databázu, pravidlo, ktoré AI nástroje na kódovanie regenerujú z dokumentácie, a pravidlo, ktoré otvára celú vašu Firestore databázu komukoľvek na internete. Tento článok presne vysvetľuje syntax, ukazuje, čo vidí útočník, keď je toto pravidlo aktívne, a poskytuje vám štyri progresívne prísnejšie náhrady, ktoré sedia na rôzne prípady použitia.

Syntax, riadok po riadku

Úplný dokument pravidiel testovacieho režimu Firestore má šesť riadkov:

firebase

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

Dekódované:

rules_version = '2'; volí v2 engine pravidiel (aktuálny). Staršie v1 pravidlá sú zastarané.
service cloud.firestore obmedzuje blok na Firestore. Realtime Database používa inú syntax založenú na JSON; Cloud Storage používa service firebase.storage.
match /databases/{database}/documents viaže špeciálnu databázu (default) (väčšina projektov má iba jednu).
match /{document=**} je rekurzívny žolík. ** zhoduje akúkoľvek cestu akejkoľvek hĺbky. V kombinácii s {document} to zachytáva každý dokument v každej kolekcii — jediná klauzula match riadi celú databázu.
allow read, write: if true; je telo pravidla. Povolené sú obe read aj write; podmienka if true je, nuž, vždy pravdivá. read pokrýva operácie get a list; write pokrýva create, update a delete.

Čistý efekt: akýkoľvek klient s Firebase project ID a správnym SDK môže čítať alebo zapisovať akýkoľvek dokument v akejkoľvek kolekcii. Autentizácia nie je potrebná. Rate limity nie sú vynucované.

Prečo Firebase dodáva toto ako predvolené

Firebase chce, aby ste kódovali v prvých 30 sekundách po vytvorení projektu. Alternatíva — donútiť vás napísať správne pravidlo predtým, než akékoľvek čítanie alebo zápis funguje — by blokovala onboarding. Takže Konzola pri vytváraní databázy ponúka dve možnosti: Production mode (odmietnuť všetko, pravidlá napíšete) alebo Test mode (povoliť všetko na 30 dní). Väčšina vývojárov klikne na testovací režim a potom zabudne sa k tomu vrátiť. Staršie projekty mali 30-dňový časovač; aktuálne projekty majú neobmedzené pravidlo if true bez automatického vypršania.

Štrukturálny problém: AI nástroje na kódovanie sa trénujú na dokumentácii, tutoriáloch a Stack Overflow odpovediach, ktoré ukazujú pravidlá testovacieho režimu. Keď sa opýtate Cursor alebo Claude Code „ako nastavím Firebase", odpoveď často zahŕňa presný blok allow read, write: if true akoby to bolo produkčné pravidlo. AI nevie — a nie je vyzvané, aby vedelo — že toto pravidlo nie je bezpečné pre produkciu.

Čo vidí útočník

Konkrétne, útočník, ktorý pozná vaše Firebase project ID (extrahovateľné z balíčka akejkoľvek nasadenej aplikácie za 30 sekúnd) a spustí nasledujúce, môže vypísať každý dokument v každej kolekcii:

Jediná neautentizovaná curl požiadavka stačí na vymenovanie každej kolekcie. Pozri zvýraznený blok nižšie.

bash

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

Odpoveďou je úplný zoznam kolekcií najvyššej úrovne. Pre každú kolekciu druhá požiadavka vráti dokumenty. Na tejto ceste nie je žiadny rate limit, pretože pravidlá if true akceptujú anonymný prenos. Videli sme Firebase databázy s miliónmi dokumentov vymenovanými za menej než hodinu.

Na ceste zápisu: jediný POST s {fields} vytvára nový dokument. Útočníci môžu znečistiť vaše kolekcie odpadkami, znetvoriť používateľské stránky, ktoré čítajú z Firestore, alebo použiť vašu databázu ako bezplatného message brokera — váš účet za používanie vyskočí, vy vyšetrujete, účet vysvetľuje problém.

Štyri produkčne bezpečné náhrady

Vyberte si náhradu, ktorá zodpovedá dátovému modelu vašej aplikácie. Všetky štyri predpokladajú, že máte autentizáciu používateľov (Firebase Auth alebo akýkoľvek poskytovateľ, ktorý vydáva Firebase ID token):

Možnosť 1: Dokumenty vlastnené používateľmi

Najčastejší SaaS vzor. Dokumenty žijú pod /users/{userId}/... a iba vlastník sa ich môže dotknúť. 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žnosť 2: Pole vlastníka na každom dokumente

Keď dokumenty žijú v plochých kolekciách (nie vnorené pod user ID), uložte pole owner_uid a skontrolujte ho. 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žnosť 3: Multi-tenant izolácia organizácie

Pre B2B SaaS s dátami obmedzenými na organizáciu. Uložte pole org_id na každom dokumente a skontrolujte ho voči vlastnému nároku používateľa. allow read, write: if request.auth.token.org_id == resource.data.org_id;. Vyžaduje nastavenie vlastného nároku počas registrácie cez Firebase Admin SDK.

firebase

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

Možnosť 4: Obsah len na čítanie verejne

Pre marketingový obsah, verejné profily, katalógy produktov — čokoľvek, čo je skutočne verejne čitateľné, ale zapisovateľné iba administrátorom. match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }. Vlastný nárok admin sa nastavuje iba na administrátorských účtoch.

firebase

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

Rýchly auditový dopyt

Pred opravou skontrolujte, či je if true skutočne aktívne. Otvorte Firebase Konzolu → Firestore → Rules a vyhľadajte if true. Ak ho nájdete kdekoľvek mimo komentára, máte nález otvoreného pravidla. Simulátor pravidiel v rovnakom UI vám umožňuje prehrať lokálne útočníkovu požiadavku — vložte anonymnú GET /users/somebody a potvrďte, že simulátor vracia Allowed.

Externé potvrdenie: spustite sken FixVibe proti vašej produkčnej URL. Kontrola baas.firebase-rules sonduje vaše pravidlá Firestore, Realtime Database a Storage a nahlasuje rovnaký nález, ktorý by objavil útočník — nezávisle od toho, čo zobrazuje Firebase Konzola.

Často kladené otázky

Aký je rozdiel medzi <code>if true</code> a <code>if request.auth != null</code>?

if true povoľuje anonymný prístup — komukoľvek na internete. if request.auth != null vyžaduje akéhokoľvek prihláseného používateľa, čo je lepšie, ale stále nesprávne: akýkoľvek používateľ vašej aplikácie môže čítať dáta každého iného používateľa. Produkčné pravidlá musia byť obmedzené na konkrétneho používateľa alebo organizáciu cez request.auth.uid == resource.data.owner_uid alebo podobné.

Vyprší Firebase niekedy automaticky pravidlá <code>if true</code>?

Staršie projekty (pred 2023) mali 30-dňový časovač, ktorý menil pravidlá if true na if false. Aktuálne projekty ho nemajú — pravidlo pretrváva donekonečna, kým sa manuálne nenahradí. Ak ste vytvorili svoj projekt pred 2023 a vaše pravidlá vyzerajú v poriadku, dvakrát skontrolujte: časovač ich už mohol prevrátiť na if false, čo blokuje vašu vlastnú aplikáciu.

Môžem použiť kontrolu časovej pečiatky s budúcim dátumom ako záchrannú sieť?

Nie — podmienka časovej pečiatky nie je bezpečnostnou kontrolou. Exspiruje otvorené pravidlo k budúcemu dátumu, čo znamená, že do tohto dátumu majú útočníci plný prístup. A vy na dátum zabudnete. Nahraďte if true pravidlom obmedzeným na autentizáciu, nie časovo viazaným.

Čo ak je moja aplikácia skutočne verejne čitateľná (blog, katalóg produktov)?

Potom explicitne napíšte allow read: if true; allow write: if false; iba na verejnej kolekcii — nie na každej kolekcii vo vašej databáze. Použite samostatnú klauzulu match na kolekciu a nikdy nepoužívajte rekurzívny žolík {document=**} na zapisovateľných pravidlách.

Ďalšie kroky

Spustite sken FixVibe proti vašej produkčnej URL — kontrola baas.firebase-rules potvrdzuje, či je if true momentálne exploitovateľné z verejného internetu. Pre mechaniku skenera a paralelné detekcie pre Realtime Database a Storage si pozrite Skener Firebase pravidiel. Pre ekvivalentnú triedu chybnej konfigurácie na Supabase si prečítajte Skener Supabase RLS.