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

Firebase allow read, write: if true verduidelik: wat dit doen en hoe om dit reg te stel

Q: Wat is die verskil tussen if true en if request.auth != null ?

if true laat anonieme toegang toe — enigiemand op die internet. if request.auth != null vereis enige aangetekende gebruiker, wat beter is maar steeds verkeerd: enige gebruiker van jou toepassing kan elke ander gebruiker se data lees. Produksie-reëls moet tot die spesifieke gebruiker of org beperk wees via request.auth.uid == resource.data.owner_uid of soortgelyks.

Q: Verstryk Firebase ooit outomaties if true -reëls?

Ouer projekte (pre-2023) het 'n 30-dae-timer gehad wat if true-reëls na if false omgeskakel het. Huidige projekte doen nie — die reël hou onbepaald aan totdat handmatig vervang. As jy jou projek voor 2023 geskep het en jou reëls lyk goed, kontroleer weer: die timer het hulle moontlik reeds na if false omgeskakel, wat jou eie toepassing blokkeer.

Q: Wat as my toepassing eg openbaar-leesbaar is (blog, produkkatalogus)?

Skryf dan eksplisiet allow read: if true; allow write: if false; op die openbare versameling alleen — nie op elke versameling in jou databasis nie. Gebruik 'n afsonderlike match-klousule per versameling en gebruik nooit die rekursiewe '{'document=**'}'-jokerteken op skryfbare reëls nie.

<code>allow read, write: if true;</code> is die enkele mees algemene Firebase-wankonfigurasie in produksie. Dit is die toets-modus-verstek wat die Firebase-Console voorstel wanneer jy 'n nuwe databasis skep, die reël wat KI-koderingsgereedskap uit dokumentasie hergenereer, en die reël wat jou hele Firestore-databasis vir enigiemand op die internet oopmaak. Hierdie artikel verduidelik die sintaks presies, wys wat 'n aanvaller sien wanneer hierdie reël lewend is, en gee jou vier progressief-strenger vervangings wat by verskillende gebruiksgevalle pas.

Die sintaks, reël vir reël

'n Volledige Firestore-toets-modus-reëls-dokument is ses reëls:

firebase

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

Gedekodeer:

rules_version = '2'; kies die v2-reëls-enjin (huidig). Ouer v1-reëls is afgekeur.
service cloud.firestore beperk die blok tot Firestore. Realtime Database gebruik 'n ander JSON-gebaseerde sintaks; Cloud Storage gebruik service firebase.storage.
match /databases/{database}/documents bind die spesiale (default)-databasis (die meeste projekte het slegs een).
match /{document=**} is 'n rekursiewe jokerteken. Die ** pas by enige pad van enige diepte. Gekombineer met {document} vang dit elke dokument in elke versameling — 'n enkele match-klousule wat die hele databasis regeer.
allow read, write: if true; is die reël-liggaam. Beide read en write word toegelaat; die voorwaarde if true is, wel, altyd waar. read dek get- en list-operasies; write dek create-, update- en delete-operasies.

Netto effek: enige kliënt met die Firebase-projek-ID en die regte SDK kan enige dokument in enige versameling lees of skryf. Autentisering word nie vereis nie. Tempolimiete word nie afgedwing nie.

Waarom Firebase dit as die verstek stuur

Firebase wil hê jy moet kodeer binne die eerste 30 sekondes na die skep van 'n projek. Die alternatief — om jou te laat 'n korrekte reël skryf voordat enige lees- of skryf-operasie werk — sou aansluiting blokkeer. Die Console bied dus twee opsies wanneer jy 'n databasis skep: Produksiemodus (weier alles, jy skryf die reëls) of Toets-modus (laat alles toe vir 30 dae). Die meeste ontwikkelaars kliek toets-modus en vergeet dan om weer te kyk. Ouer projekte het die 30-dae-timer gehad; huidige projekte het 'n onbepaalde if true-reël sonder outomatiese verstryking.

Die strukturele probleem: KI-koderingsgereedskap word opgelei op dokumentasie, tutoriale en Stack Overflow-antwoorde wat toets-modus-reëls wys. Wanneer jy Cursor of Claude Code vra "hoe stel ek Firebase op," sluit die antwoord dikwels die presiese allow read, write: if true-blok in asof dit die produksie-reël was. Die KI weet nie — en word nie aangepor om te weet nie — dat hierdie reël nie veilig vir produksie is nie.

Wat 'n aanvaller sien

Konkreet, 'n aanvaller wat jou Firebase-projek-ID ken (onttrekbaar uit enige ontplooide toepassing se bundel in 30 sekondes) en die volgende uitvoer, kan elke dokument in elke versameling lys:

'n Enkele ongeautentiseerde curl-versoek is genoeg om elke versameling te lys. Sien die uitgeligte blok hieronder.

bash

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

Die antwoord is die volledige lys van top-vlak versamelings. Vir elke versameling gee 'n tweede versoek dokumente terug. Daar is geen tempolimiet op hierdie pad nie omdat if true-reëls anonieme verkeer aanvaar. Ons het Firebase-databasisse met miljoene dokumente in minder as 'n uur sien lys.

Op die skryf-pad: 'n enkele POST met {fields} skep 'n nuwe dokument. Aanvallers kan jou versamelings met gemors besoedel, gebruiker-gerigte bladsye wat uit Firestore lees, beskadig, of jou databasis as 'n gratis boodskap-makelaar gebruik — jou gebruiksrekening styg, jy ondersoek, die rekening verduidelik die probleem.

Vier produksie-veilige vervangings

Kies die vervanging wat by jou toepassing se datamodel pas. Al vier veronderstel dat jy gebruikersautentisering het (Firebase Auth of enige verskaffer wat 'n Firebase-ID-teken uitreik):

Opsie 1: Gebruiker-besit dokumente

Mees algemene SaaS-patroon. Dokumente leef onder /users/{userId}/... en slegs die eienaar kan hulle aanraak. 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;
}

Opsie 2: Eienaar-veld op elke dokument

Wanneer dokumente in plat versamelings leef (nie geneste onder gebruiker-ID nie), stoor 'n owner_uid-veld en kontroleer dit. 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;
}

Opsie 3: Multi-huurder org-isolasie

Vir B2B SaaS met org-omvattende data. Stoor 'n org_id-veld op elke dokument en kontroleer dit teen die gebruiker se pasgemaakte aanspraak. allow read, write: if request.auth.token.org_id == resource.data.org_id;. Vereis die instelling van die pasgemaakte aanspraak tydens aanmelding via Firebase Admin-SDK.

firebase

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

Opsie 4: Slegs-lees-openbare inhoud

Vir bemarkingsinhoud, openbare profiele, produkkatalogusse — enigiets wat eg openbaar-leesbaar maar slegs-admin-skryf is. match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }. Die admin-pasgemaakte aanspraak word slegs op admin-rekeninge ingestel.

firebase

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

Vinnige oudit-navraag

Voor regstelling, kontroleer of if true werklik lewend is. Maak Firebase-Console → Firestore → Reëls oop en soek na if true. As jy dit enige plek buite 'n kommentaar vind, het jy 'n oop-reël-bevinding. Die Reëls-simulator in dieselfde UI laat jou die aanvaller se versoek plaaslik herspeel — plak 'n anonieme GET /users/somebody in en bevestig dat die simulator Toegelaat teruggee.

Eksterne bevestiging: voer 'n FixVibe-skandering teen jou produksie-URL uit. Die baas.firebase-rules-toets ondersoek jou Firestore-, Realtime-Database- en Stoor-reëls en rapporteer dieselfde bevinding wat 'n aanvaller sou ontdek — onafhanklik van wat die Firebase-Console wys.

Algemene vrae

Wat is die verskil tussen <code>if true</code> en <code>if request.auth != null</code>?

if true laat anonieme toegang toe — enigiemand op die internet. if request.auth != null vereis enige aangetekende gebruiker, wat beter is maar steeds verkeerd: enige gebruiker van jou toepassing kan elke ander gebruiker se data lees. Produksie-reëls moet tot die spesifieke gebruiker of org beperk wees via request.auth.uid == resource.data.owner_uid of soortgelyks.

Verstryk Firebase ooit outomaties <code>if true</code>-reëls?

Ouer projekte (pre-2023) het 'n 30-dae-timer gehad wat if true-reëls na if false omgeskakel het. Huidige projekte doen nie — die reël hou onbepaald aan totdat handmatig vervang. As jy jou projek voor 2023 geskep het en jou reëls lyk goed, kontroleer weer: die timer het hulle moontlik reeds na if false omgeskakel, wat jou eie toepassing blokkeer.

Kan ek 'n toekoms-datum-tydstempel-toets as 'n veiligheidsnet gebruik?

Nee — 'n tydstempel-voorwaarde is nie 'n sekuriteitsbeheer nie. Dit verstryk die oop reël op 'n toekoms-datum, wat beteken dat tot daardie datum aanvallers volle toegang het. En jy sal die datum vergeet. Vervang if true met 'n auth-beperkte reël, nie 'n tyd-beperkte een nie.

Wat as my toepassing eg openbaar-leesbaar is (blog, produkkatalogus)?

Skryf dan eksplisiet allow read: if true; allow write: if false; op die openbare versameling alleen — nie op elke versameling in jou databasis nie. Gebruik 'n afsonderlike match-klousule per versameling en gebruik nooit die rekursiewe {document=**}-jokerteken op skryfbare reëls nie.

Volgende stappe

Voer 'n FixVibe-skandering teen jou produksie-URL uit — die baas.firebase-rules-toets bevestig of if true tans uitbuitbaar is vanaf die openbare internet. Vir die skandeerder se meganika en die parallelle deteksies vir Realtime Database en Stoor, sien Firebase-reëls-skandeerder. Vir die ekwivalente wankonfigurasie-klas op Supabase, lees Supabase RLS-skandeerder.