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

Firebase allow read, write: if true útskýrt: hvað það gerir og hvernig á að laga það

Q: Hver er munurinn á if true og if request.auth != null ?

if true leyfir ókenndan aðgang — hver sem er á internetinu. if request.auth != null krefst hvers innskráðs notanda, sem er betra en samt rangt: hver notandi forritsins þíns getur lesið gögn hvers annars notanda. Framleiðslureglur verða að afmarkast við tiltekinn notanda eða org í gegnum request.auth.uid == resource.data.owner_uid eða svipað.

Q: Hvað ef forritið mitt er raunverulega opinbert-lestur (blogg, vörulisti)?

Þá skrifaðu skýrt allow read: if true; allow write: if false; aðeins á opinbera safnið — ekki á hvert safn í gagnagrunninum. Notaðu sérstaka match-ákvæði á hvert safn og notaðu aldrei endurkvæma '{'document=**'}'-jokerinn á skrifanlegar reglur.

<code>allow read, write: if true;</code> er ein algengasta Firebase-rangstilling í framleiðslu. Það er test-mode-sjálfgildið sem Firebase Console mælir með þegar þú stofnar nýjan gagnagrunn, reglan sem AI-kóðunarverkfæri endurframleiða úr skjölun, og reglan sem opnar allan Firestore-gagnagrunninn þinn fyrir hvern sem er á internetinu. Þessi grein útskýrir setningarfræðina nákvæmlega, sýnir hvað árásarmaður sér þegar þessi regla er lifandi, og gefur þér fjórar smám saman strangari skiptingar sem henta mismunandi notkunartilfellum.

Setningarfræðin, lína fyrir línu

Heilt Firestore test-mode-reglnaskjal er sex línur:

firebase

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

Afkóðað:

rules_version = '2'; velur v2-reglnavélina (núverandi). Eldri v1-reglur eru úreltar.
service cloud.firestore afmarkar blokkina við Firestore. Realtime Database notar aðra JSON-byggða setningarfræði; Cloud Storage notar service firebase.storage.
match /databases/{database}/documents bindur sérstaka (default)-gagnagrunninn (flest verkefni hafa aðeins einn).
match /{document=**} er endurkvæmur joker. ** passar við hvaða slóð sem er af hvaða dýpt sem er. Sameinað {document}, fangar þetta hvert skjal í hverju safni — ein match-ákvæði sem stjórnar öllum gagnagrunninum.
allow read, write: if true; er reglnameginhluti. Bæði read og write eru leyfð; skilyrðið if true er, jæja, alltaf satt. read nær yfir get- og list-aðgerðir; write nær yfir create, update og delete.

Nettóáhrif: hver biðlari með Firebase verkefnis-ID-inu og réttu SDK-inu getur lesið eða skrifað hvaða skjal sem er í hvaða safni sem er. Auðkenning er ekki krafist. Hraðatakmarkanir eru ekki framfylgdar.

Hvers vegna Firebase sendir þetta sem sjálfgildi

Firebase vill að þú sért að kóða á fyrstu 30 sekúndunum eftir að hafa stofnað verkefni. Valkosturinn — að láta þig skrifa rétta reglu áður en nokkur lestur eða skrif virkar — myndi hindra um-borð-komu. Svo Console býður tvo valkosti þegar þú stofnar gagnagrunn: Production mode (hafna öllu, þú skrifar reglurnar) eða Test mode (leyfa allt í 30 daga). Flestir þróunaraðilar smella á test-mode og gleyma síðan að endurskoða. Eldri verkefni höfðu 30-daga teljarann; núverandi verkefni hafa ótímabundna if true-reglu án sjálfvirks útrunna.

Skipulagslegt vandamálið: AI-kóðunarverkfæri þjálfa á skjölun, kennsluefni og Stack Overflow-svörum sem sýna test-mode-reglur. Þegar þú spyrð Cursor eða Claude Code "hvernig set ég upp Firebase," inniheldur svarið oft nákvæmlega allow read, write: if true-blokkina eins og hún væri framleiðslureglan. AI-ið veit ekki — og er ekki hvatt til að vita — að þessi regla er ekki örugg fyrir framleiðslu.

Hvað árásarmaður sér

Áþreifanlega getur árásarmaður sem þekkir Firebase verkefnis-ID-ið þitt (hægt að draga út úr knippi hvaða uppsetta forrits sem er á 30 sekúndum) og keyrir eftirfarandi, listað hvert skjal í hverju safni:

Ein óauðkennd curl-beiðni er nóg til að telja upp hvert safn. Sjá hápunktaða blokkina hér að neðan.

bash

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

Svarið er heildarlistinn yfir topplagssöfn. Fyrir hvert safn skilar önnur beiðni skjölum. Það er engin hraðatakmörkun á þessari slóð því if true-reglur samþykkja ókennda umferð. Við höfum séð Firebase-gagnagrunna með milljónum skjala taldra upp á innan við klukkustund.

Á skrifslóðinni: ein POST með {fields} býr til nýtt skjal. Árásarmenn geta mengað söfnin þín með rusli, skemmt notendavænar síður sem lesa frá Firestore, eða notað gagnagrunninn þinn sem ókeypis skilaboðamiðlara — notkunarreikningurinn þinn rýkur upp, þú rannsakar, reikningurinn útskýrir vandamálið.

Fjórar framleiðsluöruggar skiptingar

Veldu skiptinguna sem passar við gagnalíkan forritsins þíns. Allar fjórar gera ráð fyrir að þú hafir notendaauðkenningu (Firebase Auth eða einhverja veitu sem gefur út Firebase ID-tákn):

Valkostur 1: Notendaeigin skjöl

Algengasta SaaS-mynstrið. Skjöl búa undir /users/{userId}/... og aðeins eigandinn getur snert þau. 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;
}

Valkostur 2: Eigandareitur á hverju skjali

Þegar skjöl búa í flötum söfnum (ekki innfellt undir notenda-ID), geymdu owner_uid-reit og athugaðu hann. 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;
}

Valkostur 3: Fjölleigjenda org-einangrun

Fyrir B2B SaaS með org-afmörkuðum gögnum. Geymdu org_id-reit á hverju skjali og athugaðu hann gegn custom claim notandans. allow read, write: if request.auth.token.org_id == resource.data.org_id;. Krefst þess að custom claim sé stillt við skráningu í gegnum Firebase Admin SDK.

firebase

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

Valkostur 4: Lestrar-eingöngu opinbert efni

Fyrir markaðsefni, opinber prófíl, vörulista — allt sem er raunverulega opinbert-lestur en admin-eingöngu-skrif. match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }. admin-custom claim er stillt aðeins á admin-aðgangi.

firebase

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

Hröð endurskoðunarfyrirspurn

Áður en þú lagar, athugaðu hvort if true sé í raun lifandi. Opnaðu Firebase Console → Firestore → Rules og leitaðu að if true. Ef þú finnur það einhvers staðar utan athugasemdar, hefurðu opna-reglu-niðurstöðu. Rules-hermirinn í sama UI leyfir þér að spila aftur beiðni árásarmannsins staðbundið — límdu inn ókennda GET /users/somebody og staðfestu að hermirinn skili Allowed.

Utanaðkomandi staðfesting: keyrðu FixVibe-skönnun gegn framleiðslu-URL þínum. baas.firebase-rules-athugunin kannar Firestore-, Realtime Database- og Storage-reglur þínar og tilkynnir sömu niðurstöðu og árásarmaður myndi uppgötva — óháð því sem Firebase Console sýnir.

Algengar spurningar

Hver er munurinn á <code>if true</code> og <code>if request.auth != null</code>?

if true leyfir ókenndan aðgang — hver sem er á internetinu. if request.auth != null krefst hvers innskráðs notanda, sem er betra en samt rangt: hver notandi forritsins þíns getur lesið gögn hvers annars notanda. Framleiðslureglur verða að afmarkast við tiltekinn notanda eða org í gegnum request.auth.uid == resource.data.owner_uid eða svipað.

Lætur Firebase nokkurn tíma <code>if true</code>-reglur renna sjálfkrafa út?

Eldri verkefni (fyrir 2023) höfðu 30-daga teljara sem breytti if true-reglum í if false. Núverandi verkefni gera það ekki — reglan stendur ótímabundið þar til henni er handvirkt skipt út. Ef þú stofnaðir verkefnið þitt fyrir 2023 og reglurnar þínar líta vel út, tvítékkaðu: teljarinn gæti þegar hafa snúið þeim í if false, sem hindrar eigin forrit þitt.

Get ég notað framtíðar-dags-tímastimpilathugun sem öryggisnet?

Nei — tímastimpilsskilyrði er ekki öryggiseftirlit. Það lætur opnu regluna renna út á framtíðardegi, sem þýðir að árásarmenn hafa fullan aðgang þar til þá. Og þú munt gleyma dagsetningunni. Skiptu if true út fyrir auth-afmarkaða reglu, ekki tímabundna.

Hvað ef forritið mitt er raunverulega opinbert-lestur (blogg, vörulisti)?

Þá skrifaðu skýrt allow read: if true; allow write: if false; aðeins á opinbera safnið — ekki á hvert safn í gagnagrunninum. Notaðu sérstaka match-ákvæði á hvert safn og notaðu aldrei endurkvæma {document=**}-jokerinn á skrifanlegar reglur.

Næstu skref

Keyrðu FixVibe-skönnun gegn framleiðslu-URL þínum — baas.firebase-rules-athugunin staðfestir hvort if true sé núverandi nýtanlegt frá opinbera internetinu. Fyrir vélrænni skannarsins og samhliða greiningar fyrir Realtime Database og Storage, sjáðu Firebase reglnaskanni. Fyrir samsvarandi flokk rangstillingar á Supabase, lestu Supabase RLS-skanni.