Firebase allow read, write: if true azaldua: zer egiten duen eta nola konpondu

Sintaxia, lerroz lerro

Firestore test-mode arau-dokumentu oso bat sei lerro da:

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

Deskodetua:

• rules_version = '2';-k v2 arau-motorra (gaur egungoa) hautatzen du. v1 arau zaharragoak zaharkituta daude.
• service cloud.firestore-k blokea Firestoreari mugatzen dio. Realtime Database-k JSONan oinarritutako sintaxi desberdina erabiltzen du; Cloud Storage-k service firebase.storage erabiltzen du.
• match /databases/{database}/documents-k (default) datu-base berezia lotzen du (proiektu gehienek bakarra dute).
• match /{document=**} komodin errekurtsibo bat da. **-k edozein sakonerako edozein bide bat egiten du. {document}-rekin konbinaturik, bilduma bakoitzeko dokumentu bakoitza harrapatzen du — match klausula bakar batek datu-base osoa gobernatzen duela.
• allow read, write: if true; arauaren gorputza da. Bai read bai write baimenduta daude; if true baldintza, ondo, beti egia da. read-ek get eta list eragiketak biltzen ditu; write-k create, update eta delete biltzen ditu.

Eragin garbia: Firebase proiektuaren IDa eta SDK egokia dituen edozein bezerok edozein bildumako edozein dokumentu irakur edo idatz dezake. Ez da autentikaziorik behar. Ez dira aplikatzen tarifa-mugak.

Zergatik bidaltzen duen Firebase-k hau lehenetsi gisa

Firebasek nahi du proiektu bat sortu eta gero lehen 30 segundoetan kodetzen ari zaitezen. Alternatiba — edozein irakurketa edo idazketa funtzionatu aurretik arau zuzen bat idaztera behartzea — egokitzea blokeatuko luke. Beraz, Console-k bi aukera eskaintzen ditu datu-basea sortzean: Production mode (ezeztatu dena, zuk idazten dituzu arauak) edo Test mode (baimendu dena 30 egunez). Garatzaile gehienek test modua sakatzen dute, gero birbisitatzea ahaztu egiten zaie. Proiektu zaharragoek 30 eguneko denbora-neurgailua zuten; uneko proiektuek mugarik gabeko if true araua dute iraungitze automatikorik gabe.

Egiturazko arazoa: IA kodetze-tresnek test-mode arauak erakusten dituzten dokumentazio, tutorial eta Stack Overflow erantzunetan trebatzen dira. Cursor edo Claude Code-i "nola konfiguratzen dut Firebase" galdetzen diozunean, erantzuna sarritan allow read, write: if true bloke zehatza ekoizpen-arau bailitzan barne hartzen du. IAk ez daki — eta ez zaio gonbidatzen jakitea — arau hori ez dela segurua ekoizpenerako.

Erasotzaile batek zer ikusten duen

Zehazki, zure Firebase proiektuaren IDa ezagutzen duen erasotzaile batek (edozein zabaldutako aplikazioaren bundle-tik 30 segundotan atera daiteke) eta hurrengoa exekutatzen duenak bilduma bakoitzeko dokumentu bakoitza zerrendatu dezake:

Autentikatu gabeko curl eskaera bakar bat nahikoa da bilduma bakoitza zenbatzeko. Ikus behean nabarmendutako blokea.

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

Erantzuna goi-mailako bildumen zerrenda osoa da. Bilduma bakoitzeko, bigarren eskaera batek dokumentuak itzultzen ditu. Bide horretan ez dago tarifa-mugarik if true arauek trafiko anonimoa onartzen dutelako. Milioika dokumentu zenbatu diren Firebase datu-baseak ikusi ditugu ordubete baino gutxiagotan.

Idazketa-bidean: {fields}-rekin POST bakar batek dokumentu berri bat sortzen du. Erasotzaileek zure bildumak zaborrarekin kutsatu ditzakete, Firestore-tik irakurtzen duten erabiltzaileek ikusten dituzten orriak desitxuratu ditzakete edo zure datu-basea doaneko mezu-bitartekari gisa erabili — zure erabilera-faktura igotzen da, ikertzen duzu, fakturak arazoa azaltzen du.

Lau ekoizpenerako seguruko ordezpenak

Aukeratu zure aplikazioaren datu-eredua bat datorren ordezpena. Lauak suposatzen dute erabiltzaile-autentifikazioa duzula (Firebase Auth edo Firebase ID tokena igortzen duen edozein hornitzaile):

1. aukera: Erabiltzaileak duen dokumentuak

SaaS eredu arruntena. Dokumentuak /users/{userId}/... azpian bizi dira eta jabeak baino ezin du ukitu. match /users/{userId}/{document=**} { allow read, write: if request.auth != null && request.auth.uid == userId; }

match /users/{userId}/{document=**} {
  allow read, write: if request.auth != null
                     && request.auth.uid == userId;
}

2. aukera: Jabe-eremua dokumentu bakoitzean

Dokumentuak bilduma laueetan bizi direnean (ez erabiltzaile-ID azpian habiaratuta), gorde owner_uid eremu bat eta egiaztatu hura. 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; }

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;
}

3. aukera: Maizter-anitzeko erakunde-bereizketa

Erakunderako mugatutako datuak dituen B2B SaaSerako. Gorde org_id eremua dokumentu bakoitzean eta egiaztatu erabiltzailearen erreklamazio pertsonalizatuaren aurka. allow read, write: if request.auth.token.org_id == resource.data.org_id;. Sinatzean Firebase Admin SDKren bidez erreklamazio pertsonalizatua ezartzea eskatzen du.

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

4. aukera: Irakurketa-soileko eduki publikoa

Marketin edukirako, profil publikoetarako, produktuen katalogoetarako — benetan publiko-irakurketa baina admin-soilik-idazketa den edozer. match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }. admin erreklamazio pertsonalizatua admin kontuetan baino ez da ezartzen.

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

Auditoretza-kontsulta azkarra

Konpondu aurretik, egiaztatu if true bizirik dagoela. Ireki Firebase Console → Firestore → Rules eta bilatu if true. Iruzkin batetik kanpo edonon aurkitzen baduzu, arau ireki bat aurkikuntza duzu. UI bereko Rules simulagailuak erasotzailearen eskaera tokian errepikatzeko aukera ematen dizu — itsatsi anonimo GET /users/somebody bat eta egiaztatu simulagailuak Allowed itzultzen duela.

Kanpoko berrespena: egin FixVibe eskaneatze bat zure ekoizpen-URLaren aurka. baas.firebase-rules egiaztapenak zure Firestore, Realtime Database eta Storage arauak miatzen ditu eta erasotzaile batek aurkituko lukeen aurkikuntza bera jakinarazten du — Firebase Console-k erakusten duenetik independente.

Maiz egiten diren galderak

Hurrengo urratsak

Egin FixVibe eskaneatze bat zure ekoizpen-URLaren aurka — baas.firebase-rules egiaztapenak baieztatzen du if true une honetan interneteko publikotik ustiagarria den. Eskaner-mekanika eta Realtime Database eta Storage-rako paraleloko detekzioak ezagutzeko, ikus Firebase arauen eskanerra. Supabasean konfigurazio okerren klase baliokidea ikusteko, irakurri Supabase RLS eskanerra.