FixVibe

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

Firebase allow read, write: if true wedi'i esbonio: beth mae'n ei wneud a sut i'w drwsio

<code>allow read, write: if true;</code> yw'r cam-gyfluniad Firebase mwyaf cyffredin mewn cynhyrchu. Hi yw'r diofyn modd-prawf y mae Console Firebase yn ei awgrymu pan grëi gronfa ddata newydd, y rheol y mae offer codio AI yn ei hailgynhyrchu o ddogfennaeth, a'r rheol sy'n agor dy gronfa ddata Firestore gyfan i unrhyw un ar y rhyngrwyd. Mae'r erthygl hon yn esbonio'r gystrawen yn fanwl, yn dangos beth mae ymosodwr yn ei weld pan fydd y rheol hon yn fyw, ac yn rhoi pedair disodliad cynyddol-gaethach i ti sy'n cyd-fynd â gwahanol achosion defnyddio.

Y gystrawen, llinell wrth linell

Mae dogfen rheolau modd-prawf Firestore gyflawn yn chwe llinell:

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

Wedi'i ddatgodio:

  • Mae rules_version = '2'; yn dewis y peiriant rheolau v2 (cyfredol). Mae rheolau v1 hen wedi'u diraddio.
  • Mae service cloud.firestore yn cwmpasu'r bloc i Firestore. Mae Realtime Database yn defnyddio cystrawen seiliedig ar JSON wahanol; mae Cloud Storage yn defnyddio service firebase.storage.
  • Mae match /databases/{database}/documents yn rhwymo'r gronfa ddata arbennig (default) (dim ond un sydd gan y rhan fwyaf o brosiectau).
  • Mae match /{document=**} yn gerdyn gwyllt ailadroddol. Mae'r ** yn cyfateb i unrhyw lwybr o unrhyw ddyfnder. Ynghyd â {document}, mae hyn yn dal pob dogfen ym mhob casgliad — un cymal cyfatebol sy'n rheoli'r gronfa ddata gyfan.
  • Mae allow read, write: if true; yn gorff y rheol. Mae'r ddau read a write yn cael eu caniatáu; mae'r amod if true yn, wel, yn wir bob amser. Mae read yn cwmpasu gweithrediadau get a list; mae write yn cwmpasu create, update, a delete.

Effaith net: gall unrhyw gleient ag ID prosiect Firebase a'r SDK iawn ddarllen neu ysgrifennu unrhyw ddogfen mewn unrhyw gasgliad. Nid oes angen dilysu. Nid yw cyfyngiadau cyfradd yn cael eu gorfodi.

Pam mae Firebase yn llongio hwn fel y diofyn

Mae Firebase eisiau i ti fod yn codio yn y 30 eiliad cyntaf ar ôl creu prosiect. Byddai'r dewis amgen — gwneud i ti ysgrifennu rheol gywir cyn i unrhyw ddarllen neu ysgrifennu weithio — yn rhwystro ymrwymiad. Felly mae'r Console yn cynnig dau opsiwn pan grëi gronfa ddata: Modd cynhyrchu (gwadu popeth, ti sy'n ysgrifennu'r rheolau) neu Modd prawf (caniatáu popeth am 30 diwrnod). Mae'r rhan fwyaf o ddatblygwyr yn clicio modd prawf, yna'n anghofio ailymweld. Roedd gan brosiectau hŷn yr amserwr 30-diwrnod; mae gan brosiectau cyfredol reol if true amhenodol heb ddyddiad dod i ben awtomatig.

Y broblem strwythurol: mae offer codio AI yn hyfforddi ar ddogfennaeth, tiwtorialau, ac atebion Stack Overflow sy'n dangos rheolau modd-prawf. Pan fyddi'n gofyn i Cursor neu Claude Code "sut ydw i'n sefydlu Firebase," mae'r ateb yn aml yn cynnwys yr union floc allow read, write: if true fel petai'n rheol gynhyrchu. Nid yw'r AI yn gwybod — ac nid yw'n cael ei annog i wybod — nad yw'r rheol hon yn ddiogel ar gyfer cynhyrchu.

Beth mae ymosodwr yn ei weld

Yn benodol, gall ymosodwr sy'n adnabod dy ID prosiect Firebase (gellir ei echdynnu o fwndel unrhyw ap a leolwyd mewn 30 eiliad) ac sy'n rhedeg y canlynol restru pob dogfen ym mhob casgliad:

Mae un cais curl heb ei ddilysu'n ddigon i rifo pob casgliad. Gweler y bloc wedi'i amlygu isod.

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

Mae'r ymateb yn rhestr lawn o gasgliadau lefel uchaf. Ar gyfer pob casgliad, mae ail gais yn dychwelyd dogfennau. Nid oes terfyn cyfradd ar y llwybr hwn oherwydd bod rheolau if true yn derbyn traffig anhysbys. Rydym wedi gweld cronfeydd data Firebase gyda miliynau o ddogfennau'n cael eu rhifo mewn llai nag awr.

Ar y llwybr ysgrifennu: mae un POST gyda {fields} yn creu dogfen newydd. Gall ymosodwyr lygru dy gasgliadau gyda sbwriel, anharddu tudalennau sy'n wynebu defnyddwyr sy'n darllen o Firestore, neu ddefnyddio dy gronfa ddata fel broceriaeth negeseuon am ddim — mae dy fil defnydd yn cynyddu'n sydyn, ti'n ymchwilio, mae'r bil yn esbonio'r broblem.

Pedwar disodliad sy'n ddiogel mewn cynhyrchu

Dewisa'r disodliad sy'n cyd-fynd â model data dy ap. Mae'r pedwar yn cymryd yn ganiataol bod gennyt ddilysu defnyddiwr (Firebase Auth neu unrhyw ddarparwr sy'n cyhoeddi tocyn ID Firebase):

Opsiwn 1: Dogfennau sy'n eiddo i ddefnyddiwr

Patrwm SaaS mwyaf cyffredin. Mae dogfennau'n byw o dan /users/{userId}/... a dim ond y perchennog all eu cyffwrdd. 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;
}

Opsiwn 2: Maes perchennog ar bob dogfen

Pan fydd dogfennau'n byw mewn casgliadau gwastad (nid wedi'u nythu o dan ID defnyddiwr), storia faes owner_uid a'i wirio. 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;
}

Opsiwn 3: Ynysu org aml-denant

Ar gyfer SaaS B2B gyda data wedi'i gwmpasu i org. Storia faes org_id ar bob dogfen a'i wirio yn erbyn hawliad arferol y defnyddiwr. allow read, write: if request.auth.token.org_id == resource.data.org_id;. Yn gofyn gosod yr hawliad arferol yn ystod cofrestru trwy SDK Gweinyddol Firebase.

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

Opsiwn 4: Cynnwys cyhoeddus darllen-yn-unig

Ar gyfer cynnwys marchnata, proffiliau cyhoeddus, catalogau cynnyrch — unrhyw beth sy'n wir gyhoeddus-ddarllen ond gweinyddol-yn-unig-ysgrifennu. match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }. Mae'r hawliad arferol admin wedi'i osod ar gyfrifon gweinyddol yn unig.

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

Ymholiad archwilio cyflym

Cyn trwsio, gwiria a yw if true mewn gwirionedd yn fyw. Agor Console Firebase → Firestore → Rules a chwilio am if true. Os wyt yn dod o hyd iddo unrhyw le y tu allan i sylw, mae gennyt ganfyddiad rheol agored. Mae'r efelychydd Rheolau yn yr un UI yn gadael i ti ail-chwarae cais yr ymosodwr yn lleol — gludo GET /users/somebody anhysbys a chadarnhau bod yr efelychydd yn dychwelyd Caniatewyd.

Cadarnhad allanol: rheda sgan FixVibe yn erbyn dy URL cynhyrchu. Mae'r gwiriad baas.firebase-rules yn archwilio dy reolau Firestore, Realtime Database, a Storage ac yn adrodd yr un canfyddiad y byddai ymosodwr yn ei ddarganfod — yn annibynnol ar yr hyn y mae'r Console Firebase yn ei ddangos.

Cwestiynau cyffredin

Beth yw'r gwahaniaeth rhwng <code>if true</code> a <code>if request.auth != null</code>?

Mae if true yn caniatáu mynediad anhysbys — unrhyw un ar y rhyngrwyd. Mae if request.auth != null yn gofyn am unrhyw ddefnyddiwr sydd wedi mewngofnodi, sy'n well ond yn dal yn anghywir: gall unrhyw ddefnyddiwr o dy ap ddarllen data pob defnyddiwr arall. Rhaid i reolau cynhyrchu gwmpasu i'r defnyddiwr neu org penodol trwy request.auth.uid == resource.data.owner_uid neu debyg.

A yw Firebase byth yn dod i ben rheolau <code>if true</code> yn awtomatig?

Roedd gan brosiectau hŷn (cyn-2023) amserwr 30 diwrnod a oedd yn trosi rheolau if true yn if false. Nid yw prosiectau cyfredol — mae'r rheol yn parhau'n amhenodol nes ei disodli â llaw. Os crëaist dy brosiect cyn 2023 ac mae dy reolau'n edrych yn iawn, gwiria ddwywaith: efallai bod yr amserwr eisoes wedi'u troi yn if false, sy'n rhwystro dy ap dy hun.

A allaf ddefnyddio gwiriad amser-stamp dyddiad-dyfodol fel rhwyd ddiogelwch?

Na — nid yw amod amser-stamp yn rheolaeth ddiogelwch. Mae'n dod i ben y rheol agored ar ddyddiad yn y dyfodol, sy'n golygu hyd at y dyddiad hwnnw mae gan ymosodwyr fynediad llawn. A byddi'n anghofio'r dyddiad. Disodla if true â rheol wedi'i chwmpasu i auth, nid un wedi'i chyfyngu gan amser.

Beth os yw fy ap yn wir gyhoeddus-ddarllen (blog, catalog cynnyrch)?

Yna ysgrifenna'n benodol allow read: if true; allow write: if false; ar y casgliad cyhoeddus yn unig — nid ar bob casgliad yn dy gronfa ddata. Defnyddia gymal match ar wahân fesul casgliad a byth defnyddia'r cerdyn gwyllt ailadroddol {document=**} ar reolau ysgrifenadwy.

Camau nesaf

Rheda sgan FixVibe yn erbyn dy URL cynhyrchu — mae'r gwiriad baas.firebase-rules yn cadarnhau a yw if true ar hyn o bryd yn gallu cael ei gamfanteisio o'r rhyngrwyd cyhoeddus. Am fecaneg y sganiwr a'r canfyddiadau cyfochrog ar gyfer Realtime Database a Storage, gweler Sganiwr rheolau Firebase. Am y dosbarth cyfwerth o gam-gyfluniad ar Supabase, darllena Sganiwr RLS Supabase.

// sganio dy wyneb baas

Canfod y tabl agored cyn i rywun arall wneud.

Gollwng URL cynhyrchu i mewn. Mae FixVibe yn rhifo'r darparwyr BaaS y mae dy ap yn siarad â hwy, yn olrhain eu pwyntiau terfyn cyhoeddus, ac yn adrodd ar yr hyn y gall cleient heb ei ddilysu ei ddarllen neu ei ysgrifennu. Am ddim, dim gosod, dim cerdyn.

  • Haen am ddim — 3 sgan / mis, dim cerdyn cofrestru.
  • Olrhain BaaS goddefol — dim angen dilysu parth.
  • Supabase, Firebase, Clerk, Auth0, Appwrite, a mwy.
  • Awgrymiadau trwsio AI ar bob canfyddiad — gludo'n ôl i Cursor / Claude Code.
Rhedeg sgan BaaS am ddim →

dim angen cofrestru

Firebase allow read, write: if true wedi'i esbonio: beth mae'n ei wneud a sut i'w drwsio — Docs · FixVibe