Firebase allow read, write: if true förklarat: vad det gör och hur du åtgärdar det

Syntaxen, rad för rad

Ett komplett Firestore test-mode-regeldokument är sex rader:

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

Avkodat:

• rules_version = '2'; väljer v2-regel-motorn (aktuell). Äldre v1-regler är utfasade.
• service cloud.firestore avgränsar blocket till Firestore. Realtime Database använder en annan JSON-baserad syntax; Cloud Storage använder service firebase.storage.
• match /databases/{database}/documents binder den speciella (default)-databasen (de flesta projekt har bara en).
• match /{document=**} är ett rekursivt wildcard. ** matchar varje sökväg på varje djup. Kombinerat med {document} fångar detta varje dokument i varje collection — en enda match-klausul som styr hela databasen.
• allow read, write: if true; är regelkroppen. Både read och write är tillåtna; villkoret if true är, ja, alltid sant. read täcker get- och list-operationer; write täcker create, update och delete.

Nettoeffekt: vilken klient som helst med Firebase-projekt-ID:t och rätt SDK kan läsa eller skriva vilket dokument som helst i vilken collection som helst. Autentisering krävs inte. Rate limits tvingas inte fram.

Varför Firebase levererar det här som default

Firebase vill att du kodar inom de första 30 sekunderna efter att du skapat ett projekt. Alternativet — att tvinga dig att skriva en korrekt regel innan någon läsning eller skrivning fungerar — skulle blockera onboardingen. Så konsolen erbjuder två alternativ när du skapar en databas: Production mode (neka allt, du skriver reglerna) eller Test mode (tillåt allt i 30 dagar). De flesta utvecklare klickar test mode och glömmer sedan att återbesöka. Äldre projekt hade 30-dagarstimern; aktuella projekt har en obegränsad if true-regel utan automatiskt förfall.

Det strukturella problemet: AI-kodningsverktyg tränar på dokumentation, handledningar och Stack Overflow-svar som visar test-mode-regler. När du frågar Cursor eller Claude Code "hur sätter jag upp Firebase", innehåller svaret ofta exakt allow read, write: if true-blocket som om det vore produktionsregeln. AI:n vet inte — och uppmanas inte att veta — att regeln inte är säker för produktion.

Vad en angripare ser

Konkret kan en angripare som känner till ditt Firebase-projekt-ID (extraherbart från vilken deployad apps bundle som helst på 30 sekunder) och kör följande lista varje dokument i varje collection:

En enda oautentiserad curl-förfrågan räcker för att räkna upp varje collection. Se det markerade blocket nedan.

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

Svaret är hela listan över top-level-collections. För varje collection returnerar en andra förfrågan dokument. Det finns ingen rate limit på den vägen eftersom if true-regler accepterar anonym trafik. Vi har sett Firebase-databaser med miljontals dokument uppräknade på under en timme.

På skrivvägen: en enda POST med {fields} skapar ett nytt dokument. Angripare kan smutskasta dina collections med skräp, defacea användarsidor som läser från Firestore eller använda din databas som en gratis message broker — din användningsfaktura skenar, du undersöker, fakturan förklarar problemet.

Fyra produktionssäkra ersättningar

Välj den ersättning som matchar din apps datamodell. Alla fyra förutsätter att du har användarautentisering (Firebase Auth eller någon leverantör som utfärdar en Firebase ID-token):

Alternativ 1: Användarägda dokument

Vanligaste SaaS-mönstret. Dokument lever under /users/{userId}/... och endast ägaren kan röra dem. 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;
}

Alternativ 2: Ägarfält på varje dokument

När dokument lever i platta collections (inte nästade under användar-ID), lagra ett owner_uid-fält och kontrollera det. 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;
}

Alternativ 3: Multi-tenant-org-isolering

För B2B-SaaS med org-avgränsad data. Lagra ett org_id-fält på varje dokument och kontrollera det mot användarens custom claim. allow read, write: if request.auth.token.org_id == resource.data.org_id;. Kräver att custom claim sätts vid registrering via Firebase Admin SDK.

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

Alternativ 4: Endast-läs publikt innehåll

För marknadsföringsinnehåll, publika profiler, produktkataloger — allt som är genuint publikt-läsbart men endast skrivbart av admin. match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }. admin-custom claim sätts endast på admin-konton.

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

Snabb granskningsfråga

Innan du fixar, kontrollera om if true faktiskt är aktivt. Öppna Firebase-konsolen → Firestore → Rules och sök efter if true. Hittar du det någonstans utanför en kommentar har du ett öppen-regel-fynd. Rules-simulatorn i samma UI låter dig spela upp angriparens förfrågan lokalt — klistra in en anonym GET /users/somebody och bekräfta att simulatorn returnerar Allowed.

Extern bekräftelse: kör en FixVibe-scanning mot din produktions-URL. baas.firebase-rules-checken sonderar dina Firestore-, Realtime Database- och Storage-regler och rapporterar samma fynd som en angripare skulle upptäcka — oberoende av vad Firebase-konsolen visar.

Vanliga frågor

Nästa steg

Kör en FixVibe-scanning mot din produktions-URL — baas.firebase-rules-checken bekräftar om if true för närvarande kan utnyttjas från det publika internetet. För scanner-mekaniken och parallella detektioner för Realtime Database och Storage, se Firebase rules-scanner. För motsvarande felkonfigurationsklass i Supabase, läs Supabase RLS-scanner.