FixVibe

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

Firebase allow read, write: if true vysvětleno: co to dělá a jak to opravit

<code>allow read, write: if true;</code> je jediná nejčastější chybná konfigurace Firebase v produkci. Je to výchozí test-mode, který Firebase Console navrhuje při vytvoření nové databáze, pravidlo, které AI nástroje pro kódování regenerují z dokumentace, a pravidlo, které otevírá celou vaši databázi Firestore komukoliv na internetu. Tento článek vysvětluje syntaxi přesně, ukazuje, co útočník vidí, když je toto pravidlo živé, a dává vám čtyři postupně přísnější náhrady, které vyhovují různým případům použití.

Syntaxe, řádek po řádku

Kompletní dokument pravidel Firestore test-mode má šest řádků:

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

Dekódováno:

  • rules_version = '2'; vybírá engine pravidel v2 (aktuální). Starší pravidla v1 jsou zastaralá.
  • service cloud.firestore omezuje blok na Firestore. Realtime Database používá jinou JSON-založenou syntaxi; Cloud Storage používá service firebase.storage.
  • match /databases/{database}/documents váže speciální databázi (default) (většina projektů má jen jednu).
  • match /{document=**} je rekurzivní zástupný znak. ** odpovídá jakékoliv cestě v jakékoliv hloubce. V kombinaci s {document} to zachytává každý dokument v každé kolekci — jediná klauzule match řídí celou databázi.
  • allow read, write: if true; je tělem pravidla. Povoleno je jak read, tak write; podmínka if true je, no, vždy pravdivá. read pokrývá operace get a list; write pokrývá create, update a delete.

Čistý efekt: jakýkoliv klient s ID projektu Firebase a správným SDK může číst nebo zapisovat jakýkoliv dokument v jakékoliv kolekci. Autentizace není vyžadována. Limity rychlosti nejsou vynucovány.

Proč Firebase toto dodává jako výchozí

Firebase chce, abyste kódovali v prvních 30 sekundách po vytvoření projektu. Alternativa — donutit vás napsat správné pravidlo, než cokoliv funguje pro čtení nebo zápis — by blokovala onboarding. Takže Console nabízí dvě možnosti při vytváření databáze: Production mode (odmítnout vše, pravidla napíšete sami) nebo Test mode (povolit vše po dobu 30 dnů). Většina vývojářů klikne na test mode a pak zapomene to revidovat. Starší projekty měly 30denní časovač; aktuální projekty mají neomezené pravidlo if true bez automatické expirace.

Strukturální problém: AI nástroje pro kódování trénují na dokumentaci, tutoriálech a odpovědích Stack Overflow, které ukazují test-mode pravidla. Když se zeptáte Cursor nebo Claude Code "jak nastavím Firebase", odpověď často obsahuje přesný blok allow read, write: if true, jako by to bylo produkční pravidlo. AI neví — a není mu řečeno, aby vědělo — že toto pravidlo není bezpečné pro produkci.

Co útočník vidí

Konkrétně útočník, který zná vaše ID projektu Firebase (extrahovatelné z balíčku jakékoliv nasazené aplikace za 30 sekund) a spustí následující, může vypsat každý dokument v každé kolekci:

Jediný neověřený curl požadavek stačí k enumeraci každé kolekce. Viz zvýrazněný blok níže.

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

Odpovědí je úplný seznam kolekcí nejvyšší úrovně. Pro každou kolekci druhý požadavek vrátí dokumenty. Na této cestě není rate limit, protože pravidla if true přijímají anonymní provoz. Viděli jsme databáze Firebase s miliony dokumentů enumerovanými za méně než hodinu.

Na cestě zápisu: jediný POST s {fields} vytvoří nový dokument. Útočníci mohou zaplevelit vaše kolekce harampádím, znetvořit uživatelsky orientované stránky, které čtou z Firestore, nebo použít vaši databázi jako bezplatný message broker — váš účet za používání vyskočí, vy to zkoumáte, účet vysvětluje problém.

Čtyři produkčně bezpečné náhrady

Vyberte náhradu, která odpovídá datovému modelu vaší aplikace. Všechny čtyři předpokládají, že máte autentizaci uživatelů (Firebase Auth nebo jakéhokoliv poskytovatele, který vydává Firebase ID token):

Možnost 1: Dokumenty vlastněné uživateli

Nejběžnější SaaS vzor. Dokumenty žijí pod /users/{userId}/... a může se jich dotknout pouze vlastník. 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: Pole vlastníka na každém dokumentu

Když dokumenty žijí v plochých kolekcích (nikoliv vnořené pod ID uživatele), uložte pole owner_uid a zkontrolujte 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žnost 3: Vícenájemní org izolace

Pro B2B SaaS s daty omezenými na org. Uložte pole org_id na každém dokumentu a zkontrolujte ho proti vlastnímu nároku uživatele. allow read, write: if request.auth.token.org_id == resource.data.org_id;. Vyžaduje nastavení vlastního nároku během registrace přes Firebase Admin SDK.

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

Možnost 4: Veřejný obsah pouze pro čtení

Pro marketingový obsah, veřejné profily, katalogy produktů — cokoliv, co je skutečně veřejně čitelné, ale pouze admin píše. match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }. Vlastní nárok admin je nastaven pouze na admin účtech.

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

Rychlý auditní dotaz

Před opravou zkontrolujte, zda je if true skutečně živé. Otevřete Firebase Console → Firestore → Rules a hledejte if true. Pokud ho najdete kdekoliv mimo komentář, máte nález otevřeného pravidla. Simulátor pravidel ve stejném UI vám umožňuje lokálně přehrát požadavek útočníka — vložte anonymní GET /users/somebody a potvrďte, že simulátor vrací Allowed.

Externí potvrzení: spusťte FixVibe sken proti vaší produkční URL. Kontrola baas.firebase-rules sonduje vaše pravidla Firestore, Realtime Database a Storage a hlásí stejný nález, který by objevil útočník — nezávisle na tom, co Firebase Console ukazuje.

Často kladené otázky

Jaký je rozdíl mezi <code>if true</code> a <code>if request.auth != null</code>?

if true povoluje anonymní přístup — komukoliv na internetu. if request.auth != null vyžaduje jakéhokoliv přihlášeného uživatele, což je lepší, ale stále špatné: jakýkoliv uživatel vaší aplikace může číst data každého jiného uživatele. Produkční pravidla musí být omezena na konkrétního uživatele nebo org přes request.auth.uid == resource.data.owner_uid nebo podobně.

Nechá Firebase někdy automaticky expirovat pravidla <code>if true</code>?

Starší projekty (před 2023) měly 30denní časovač, který převáděl pravidla if true na if false. Aktuální projekty ho nemají — pravidlo přetrvává neomezeně, dokud není ručně nahrazeno. Pokud jste si projekt vytvořili před rokem 2023 a vaše pravidla vypadají v pořádku, dvakrát zkontrolujte: časovač je možná již převedl na if false, což blokuje vaši vlastní aplikaci.

Mohu použít kontrolu časového razítka v budoucnosti jako záchrannou síť?

Ne — podmínka časového razítka není bezpečnostní kontrola. Expiruje otevřené pravidlo k budoucímu datu, což znamená, že do toho data mají útočníci úplný přístup. A vy zapomenete na to datum. Nahraďte if true pravidlem omezeným na ověření, nikoliv časově omezeným.

Co když je moje aplikace skutečně veřejně čitelná (blog, katalog produktů)?

Pak explicitně napište allow read: if true; allow write: if false; pouze na veřejné kolekci — ne na každé kolekci ve vaší databázi. Použijte samostatnou klauzuli match na kolekci a nikdy nepoužívejte rekurzivní zástupný znak {document=**} na zapisovatelná pravidla.

Další kroky

Spusťte FixVibe sken proti vaší produkční URL — kontrola baas.firebase-rules potvrdí, zda je if true aktuálně zneužitelné z veřejného internetu. Pro mechaniku skeneru a paralelní detekce pro Realtime Database a Storage viz Skener pravidel Firebase. Pro ekvivalentní třídu chybné konfigurace na Supabase si přečtěte Skener Supabase RLS.

// naskenujte svůj baas povrch

Najděte otevřenou tabulku dříve, než to udělá někdo jiný.

Zadejte produkční URL. FixVibe vyjmenuje poskytovatele BaaS, se kterými vaše aplikace komunikuje, sejme otisky jejich veřejných koncových bodů a nahlásí, co může neověřený klient číst nebo zapisovat. Zdarma, bez instalace, bez karty.

  • Bezplatná úroveň — 3 skeny / měsíc, bez karty při registraci.
  • Pasivní snímání otisků BaaS — bez nutnosti ověření domény.
  • Supabase, Firebase, Clerk, Auth0, Appwrite a další.
  • AI návrhy oprav u každého nálezu — vložte zpět do Cursor / Claude Code.
Spustit bezplatný sken BaaS →

registrace není potřeba

Firebase allow read, write: if true vysvětleno: co to dělá a jak to opravit — Docs · FixVibe