Firebase allow read, write: if true magyarázat: mit csinál és hogyan javítsd

A szintaxis, sorról sorra

Egy teljes Firestore test-mode szabálydokumentum hat soros:

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

Dekódolva:

• rules_version = '2'; kiválasztja a v2 szabálymotort (aktuális). A régebbi v1 szabályok elavultak.
• service cloud.firestore a blokkot a Firestore-ra szűkíti. A Realtime Database egy másik JSON-alapú szintaxist használ; a Cloud Storage a service firebase.storage-ot használja.
• match /databases/{database}/documents a speciális (default) adatbázishoz köt (a legtöbb projektnek csak egy van).
• match /{document=**} egy rekurzív wildcard. A ** bármilyen mélységű útvonalra illeszkedik. A {document}-mel kombinálva ez rögzít minden dokumentumot minden kollekcióban — egyetlen match záradék, ami az egész adatbázist kormányozza.
• allow read, write: if true; a szabály törzse. Mind a read, mind a write engedélyezett; a feltétel if true, nos, mindig igaz. A read lefedi a get és list műveleteket; a write lefedi a create, update és delete műveleteket.

Nettó hatás: bármely kliens a Firebase projekt-azonosítóval és a megfelelő SDK-val képes bármely dokumentumot olvasni vagy írni bármely kollekcióban. Hitelesítés nem szükséges. Rate-limitek nincsenek érvényesítve.

Miért szállítja a Firebase ezt alapértelmezésként

A Firebase azt akarja, hogy az első 30 másodpercben, miután létrehoztál egy projektet, már kódolj. Az alternatíva — hogy egy helyes szabály megírására kényszerítsen, mielőtt bármilyen olvasás vagy írás működne — blokkolná az onboardingot. Tehát a Console két opciót kínál, amikor adatbázist hozol létre: Production mode (minden megtagad, te írod a szabályokat) vagy Test mode (mindent megenged 30 napig). A legtöbb fejlesztő a test mode-ra kattint, majd elfelejti újragondolni. A régebbi projekteknél 30 napos időzítő volt; a jelenlegi projekteknek határozatlan if true szabályuk van automatikus lejárat nélkül.

A strukturális probléma: az MI-kódoló eszközök olyan dokumentációkon, oktatóanyagokon és Stack Overflow-válaszokon tanulnak, amelyek test-mode szabályokat mutatnak. Amikor megkérdezed a Cursort vagy a Claude Code-ot, hogy „hogyan állítok be Firebase-t", a válasz gyakran tartalmazza pontosan az allow read, write: if true blokkot, mintha ez lenne a produkciós szabály. Az MI nem tudja — és nem is kapja meg az utasítást, hogy tudja —, hogy ez a szabály nem biztonságos produkcióhoz.

Mit lát egy támadó

Konkrétan egy támadó, aki ismeri a Firebase projekt-azonosítódat (30 másodperc alatt kinyerhető bármely deployolt alkalmazás bundle-jéből), és a következőt futtatja, képes listázni minden dokumentumot minden kollekcióban:

Egyetlen nem hitelesített curl-kérés elég minden kollekció enumerálásához. Lásd a kiemelt blokkot alább.

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

A válasz a felső szintű kollekciók teljes listája. Minden kollekcióra egy második kérés dokumentumokat ad vissza. Nincs rate-limit ezen az útvonalon, mert az if true szabályok elfogadják az anonim forgalmat. Láttunk olyan Firebase-adatbázisokat, amelyekben milliós nagyságrendű dokumentumokat enumeráltak egy óránál is rövidebb idő alatt.

Az írási útvonalon: egyetlen POST {fields}-szel létrehoz egy új dokumentumot. A támadók szeméttel beszennyezhetik a kollekcióidat, megrongálhatják a Firestore-ból olvasó felhasználói oldalakat, vagy az adatbázisodat ingyenes message brokerként használhatják — a használati számlád megugrik, vizsgálódsz, a számla megmagyarázza a problémát.

Négy produkció-biztos helyettesítés

Válaszd ki azt a helyettesítést, ami illik az alkalmazásod adatmodelljéhez. Mind a négy azt feltételezi, hogy van felhasználói hitelesítésed (Firebase Auth vagy bármely szolgáltató, ami Firebase ID tokent ad ki):

1. opció: Felhasználó-tulajdonú dokumentumok

A leggyakoribb SaaS-minta. A dokumentumok /users/{userId}/... alatt élnek, és csak a tulajdonos érintheti őket. 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. opció: Tulajdonosmező minden dokumentumon

Amikor a dokumentumok lapos kollekciókban élnek (nem felhasználó-azonosító alá ágyazva), tárolj egy owner_uid mezőt, és ellenőrizd. 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. opció: Multi-tenant org-izoláció

B2B SaaS-hez, org-szűkített adatokkal. Tárolj egy org_id mezőt minden dokumentumon, és ellenőrizd a felhasználó custom claim-je ellen. allow read, write: if request.auth.token.org_id == resource.data.org_id;. Megköveteli a custom claim beállítását regisztráció során a Firebase Admin SDK-n keresztül.

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

4. opció: Csak olvasható nyilvános tartalom

Marketing-tartalmakhoz, nyilvános profilokhoz, termékkatalógusokhoz — bármihez, ami valóban nyilvánosan olvasható, de csak admin-által írható. match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }. Az admin custom claim csak admin-fiókokon van beállítva.

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

Gyors audit-lekérdezés

Javítás előtt ellenőrizd, hogy az if true ténylegesen él. Nyisd meg a Firebase Console → Firestore → Rules menüpontot, és keress az if true-ra. Ha bárhol megtalálod kommenten kívül, akkor van nyitott-szabály találatod. Az ugyanezen UI-ban lévő Rules szimulátor lehetővé teszi, hogy lokálisan visszajátszd a támadó kérését — illessz be egy anonim GET /users/somebody-t, és erősítsd meg, hogy a szimulátor Allowed-et ad vissza.

Külső megerősítés: futtass egy FixVibe-szkennelést az éles URL-edre. A baas.firebase-rules ellenőrzés szondázza a Firestore-, Realtime Database- és Storage-szabályaidat, és ugyanazt a találatot jelenti, amit egy támadó felfedezne — függetlenül attól, hogy mit mutat a Firebase Console.

Gyakori kérdések

Következő lépések

Futtass egy FixVibe-szkennelést az éles URL-edre — a baas.firebase-rules ellenőrzés megerősíti, hogy az if true jelenleg kihasználható-e a nyilvános internetről. A szkenner mechanikájáért és a Realtime Database és Storage párhuzamos detektálásaiért lásd Firebase rules szkenner. A Supabase-en lévő ekvivalens hibás konfigurációs osztályért olvasd el Supabase RLS-szkenner.