FixVibe

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

Firebase allow read, write: if true greiðað: hvat tað ger og hvussu at laga tað

<code>allow read, write: if true;</code> er hin einasta vanligasta Firebase-misskipanin í framleiðslu. Tað er hin royndarmodul-standardurin, sum Firebase Console mælir til, tá tú stovnar ein nýggjan dátugrunn, reglan, sum AI-kotuamboð endurframleiða frá skjalfestingar-dømum, og reglan, sum lukkar opna tín heila Firestore-dátugrunn fyri hvør tann á alnetinum. Henda greinin greiðir frá syntaksini neyvt, vísir, hvat ein árásarmaður sær, tá henda reglan er virkin, og gevur tær fýra trimum strangari útskiftingar, sum eru við ymiskum nýtsluferunum.

Syntaksin, lina fyri lina

Eitt fult Firestore royndar-modul reglu-skjal er seks linur:

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

Avkodað:

  • rules_version = '2'; velur v2-reglu-motorin (verandi). Eldri v1-reglur eru útgingnar.
  • service cloud.firestore avmarkar blokkin til Firestore. Realtime Database brúkar eina aðra JSON-baseraða syntaks; Cloud Storage brúkar service firebase.storage.
  • match /databases/{database}/documents bindur hin serliga (default)-dátugrunnin (tey flestu projektini hava bert ein).
  • match /{document=**} er eitt rekursivt vild-tegn. ** samsvarar einhvørjari leið á einhvørjum dýpti. Saman við {document} fangar hetta hvørt skjal í hvørjari collection — eitt einstakt match-klausul, sum stýrir heilum dátugrunninum.
  • allow read, write: if true; er reglu-kroppurin. Bæði read og write verða loyvd; treytin if true er, ja, altíð satt. read umfatar get- og list-uppgerðir; write umfatar create, update og delete.

Netto avleiðing: hvør klientur við Firebase-projekt-ID og rættu SDK kann lesa ella skriva hvørt skjal í hvørjari collection. Váttan er ikki kravd. Markar verða ikki framtvingaðar.

Hví Firebase sendir hetta sum standard

Firebase vil hava teg at kotara í fyrstu 30 sekundum eftir stovning av einum projekti. Annað val — at fáa teg at skriva eina rætta reglu, áðrenn nakar lestur ella skriving virkar — vildi steðgað innskriving. So Console gevur tveir valkostir, tá tú stovnar ein dátugrunn: Production mode (nokta alt, tú skrivar reglurnar) ella Test mode (loyv alt í 30 dagar). Tey flestu menningarmenn klikkja royndarmodul og gloyma síðan at vita aftur. Eldri projekt høvdu 30-daga-tíðina; verandi projekt hava eina ótíðar if true-reglu uttan sjálvirkandi útrunningi.

Hin strukturella trupulleikin: AI-kotuamboð venja á skjalfesting, læristøðum og Stack Overflow-svørum, sum vísa royndarmodul-reglur. Tá tú spyrt Cursor ella Claude Code "hvussu seti eg Firebase upp," inniheldur svarið ofta neyva allow read, write: if true-blokkin, sum um tað var framleiðslu-reglan. AI'in veit ikki — og verður ikki spurt at vita — at henda reglan er ikki trygg fyri framleiðslu.

Hvat árásarmaður sær

Konkret kann ein árásarmaður, sum veit tín Firebase-projekt-ID (uppgøtanligt frá hvørjari deployaðu appins bunka í 30 sekundum) og koyrir fylgjandi, lista hvørt skjal í hvørjari collection:

Ein einstøk óvátt curl-fyrispurning er nóg mikið til at telja hvørja collection upp. Sí merkta blokkin niðanfyri.

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

Svarið er heili listin av topp-stigs-collections. Fyri hvørja collection gevur ein onnur fyrispurning skjøl aftur. Tað er eingin mark á hesari leið, av tí at if true-reglur góðtaka anonyma trafikk. Vit hava sæð Firebase-dátugrunnar við milliónum skjøla taldar upp á minni enn einum tíma.

Á skriva-leiðini: ein einstøk POST við {fields} stovnar eitt nýtt skjal. Árásarmenn kunnu mengja tínar collections við ruski, vansigna brúkara-vendar síður, sum lesa frá Firestore, ella brúka tín dátugrunn sum eina ókeypis boð-mikkulingu — tín nýtsluroknroknarinn hækkar, tú granskar, og rokningin greiðir trupulleikan.

Fýra framleiðslu-tryggar útskiftingar

Vel útskiftingina, sum samsvarar appins dátu-modul. Allar fýra ætla, at tú hevur brúkara-váttan (Firebase Auth ella nakar veitari, sum gevur Firebase ID-token):

Valkost 1: Brúkara-ogandi skjøl

Mest vanliga SaaS-mynstur. Skjøl búgva undir /users/{userId}/... og bert ogandi kann nerta tey. 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;
}

Valkost 2: Ogandi-felt á hvørjum skjali

Tá skjøl búgva í flatum collections (ikki nestaðar undir brúkara-ID), goym eitt owner_uid-felt og kanna tað. 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;
}

Valkost 3: Fleir-leigara org-einangring

Fyri B2B SaaS við org-avmarkaðum dátum. Goym eitt org_id-felt á hvørjum skjali og kanna tað ímóti brúkaras sergjørda krøvi. allow read, write: if request.auth.token.org_id == resource.data.org_id;. Krevur at seta sergjørda krøvið undir innskriving gjøgnum Firebase Admin SDK.

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

Valkost 4: Bert-lestur almenn innihald

Fyri marknaðar-innihald, almennar prófilir, vørukatalogr — alt, sum verulig er almenn-lestur men admin-bert-skriva. match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }. admin-sergjørda krøvið er sett bert á admin-kontur.

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

Skjótur endurskoðanar-fyrispurningur

Áðrenn fixa, kanna um if true er veruliga virkin. Lat Firebase Console → Firestore → Rules upp og leita eftir if true. Um tú finnur tað nakranstaðni uttan fyri ein viðmerkin, hevur tú ein opin-reglu-finding. Rules simulator í somu UI letir teg endurspæla árásarmansins fyrispurning staðiliga — innset eitt óvátt GET /users/somebody og vátta at simulatorin gevur Allowed aftur.

Uttarlig vátting: koyr eina FixVibe-skanning móti tíni framleiðslu-URL. baas.firebase-rules-eftirkanningin royndar tínar Firestore-, Realtime Database- og Storage-reglur og fráboðar somu finding, sum ein árásarmaður vildi funnið — óhevjað av tí, sum Firebase Console vísir.

Ofta settir spurningar

Hvør er munurin á <code>if true</code> og <code>if request.auth != null</code>?

if true loyvir anonyma atgongd — hvør tann á alnetinum. if request.auth != null krevur nakran innskrivaðan brúkara, sum er betri men enn skeivt: hvør brúkari av tíni app kann lesa hvørs annars brúkaras dátur. Framleiðslureglur mega vera avmarkaðar til hin sergreina brúkara ella org gjøgnum request.auth.uid == resource.data.owner_uid ella umlíkt.

Útrennur Firebase nakrar tíðir sjálvirkandi <code>if true</code>-reglur?

Eldri projekt (fyri 2023) høvdu eitt 30-daga-tíðir, sum broytti if true-reglur til if false. Verandi projekt gera ikki — reglan er varandi, til hon er handfarið útskift. Um tú stovnaði tín projekt fyri 2023 og tínar reglur sjáa væl út, dobbel-kanna: tíðin kann longu hava broytt tær til if false, sum blokkar tína egnu app.

Kann eg brúka eina framtíðar-dag-tíðarmerki-kanning sum eitt trygdar-net?

Nei — ein tíðarmerki-treyt er ikki ein trygdar-stýring. Hon útrennur opnu regluni á einum framtíðar dagi, sum merkir at til tann dag hava árásarmenn fulla atgongd. Og tú gloymir dagin. Skift if true út fyri eina váttan-avmarkaða reglu, ikki eina tíðar-avmarkaða.

Hvat um mín app er veruliga almenn-lestur (blog, vørukatalogur)?

So skriva greitt allow read: if true; allow write: if false; bert á hinari almennu collection — ikki á hvørjari collection í tínum dátugrunni. Brúk eina sertska match-klausul per collection og brúk ongantíð rekursivu {document=**}-vild-tegnið á skriva-reglum.

Næstu stig

Koyr eina FixVibe-skanning móti tíni framleiðslu-URL — baas.firebase-rules-eftirkanningin váttar, um if true er útnýtanlig frá hinum almenna alnetinum. Fyri skannara-mekanikkin og parallelar uppgøtanir fyri Realtime Database og Storage, sí Firebase reglu-skannara. Fyri tann samsvarandi flokk av misskipan á Supabase, les Supabase RLS-skannari.

// skanna tína baas-yvirflatu

Finn ta opnu talvuna, áðrenn onkur annar ger tað.

Set eina framleiðslu-URL inn. FixVibe telur upp tær BaaS-veitarar, sum tín app tosar við, fingraavryggjar teirra alment endapunkt og fráboðar, hvat ein óvátt klientur kann lesa ella skriva. Ókeypis, eingin innleggjing, eitt einki kort.

  • Ókeypis støði — 3 skanningar/mánaði, einki kort við tilmelding.
  • Passiv BaaS-fingraavrygging — eingin domena-vátting kravd.
  • Supabase, Firebase, Clerk, Auth0, Appwrite og fleiri.
  • AI-fix-leiðbeiningar á hvørjari findingi — set aftur inn í Cursor / Claude Code.
Firebase allow read, write: if true greiðað: hvat tað ger og hvussu at laga tað — Docs · FixVibe