Firebase allow read, write: if true forklart: hva det gjør og hvordan du fikser det

Syntaksen, linje for linje

Et komplett Firestore test-mode-regeldokument er seks linjer:

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

Dekodet:

• rules_version = '2'; velger v2-regelmotoren (gjeldende). Eldre v1-regler er utfaset.
• service cloud.firestore avgrenser blokken til Firestore. Realtime Database bruker en annen JSON-basert syntaks; Cloud Storage bruker service firebase.storage.
• match /databases/{database}/documents binder den spesielle (default)-databasen (de fleste prosjekter har bare én).
• match /{document=**} er et rekursivt wildcard. ** matcher en hvilken som helst sti på et hvilket som helst dybde. Kombinert med {document} fanger dette hvert dokument i hver collection — en enkelt match-klausul som styrer hele databasen.
• allow read, write: if true; er regelkroppen. Både read og write tillates; betingelsen if true er, vel, alltid sann. read dekker get- og list-operasjoner; write dekker create, update og delete.

Nettoeffekt: enhver klient med Firebase-prosjekt-ID-en og riktig SDK kan lese eller skrive et hvilket som helst dokument i en hvilken som helst collection. Autentisering kreves ikke. Rate limits håndheves ikke.

Hvorfor Firebase leverer dette som standard

Firebase vil at du skal kode innen de første 30 sekundene etter at du har opprettet et prosjekt. Alternativet — å tvinge deg til å skrive en korrekt regel før noen lesing eller skriving fungerer — ville blokkere onboarding. Så Console tilbyr to alternativer når du oppretter en database: Production mode (nekt alt, du skriver reglene) eller Test mode (tillat alt i 30 dager). De fleste utviklere klikker test-mode og glemmer å besøke det igjen. Eldre prosjekter hadde 30-dagers-timeren; gjeldende prosjekter har en ubegrenset if true-regel uten automatisk utløp.

Det strukturelle problemet: AI-kodeverktøy trener på dokumentasjon, opplæringsmateriell og Stack Overflow-svar som viser test-mode-regler. Når du spør Cursor eller Claude Code "hvordan setter jeg opp Firebase," inneholder svaret ofte den eksakte allow read, write: if true-blokken som om det var produksjonsregelen. AI-en vet ikke — og oppfordres ikke til å vite — at denne regelen ikke er trygg for produksjon.

Hva en angriper ser

Konkret kan en angriper som kjenner Firebase-prosjekt-ID-en din (hentbar fra en hvilken som helst deployet apps bundle på 30 sekunder) og kjører følgende, liste hvert dokument i hver collection:

En enkelt uautentisert curl-request er nok til å enumerere hver collection. Se den uthevede blokken nedenfor.

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

Svaret er den fulle listen over toppnivå-collections. For hver collection returnerer en andre request dokumenter. Det finnes ingen rate limit på denne stien fordi if true-regler aksepterer anonym trafikk. Vi har sett Firebase-databaser med millioner av dokumenter enumerert på under en time.

På skrivestien: en enkelt POST med {fields} oppretter et nytt dokument. Angripere kan forurense collections med søppel, vandalisere brukerrettede sider som leser fra Firestore, eller bruke databasen din som en gratis message broker — bruksregningen din skyter i været, du etterforsker, regningen forklarer problemet.

Fire produksjonssikre erstatninger

Velg erstatningen som passer appens datamodell. Alle fire antar at du har brukerautentisering (Firebase Auth eller en hvilken som helst leverandør som utsteder et Firebase ID-token):

Alternativ 1: Brukereide dokumenter

Vanligste SaaS-mønster. Dokumenter lever under /users/{userId}/... og kun eieren kan røre 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: Eierfelt på hvert dokument

Når dokumenter lever i flate collections (ikke nestet under bruker-ID), lagre et owner_uid-felt og sjekk 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

For B2B-SaaS med org-avgrensede data. Lagre et org_id-felt på hvert dokument og sjekk det mot brukerens custom claim. allow read, write: if request.auth.token.org_id == resource.data.org_id;. Krever at custom claim settes ved registrering via Firebase Admin SDK.

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

Alternativ 4: Kun-lesing offentlig innhold

For markedsføringsinnhold, offentlige profiler, produktkataloger — alt som er genuint offentlig-lesbart, men kun-admin-skrivbart. match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }. admin-custom claim settes kun på admin-kontoer.

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

Rask granskingsspørring

Før du fikser, sjekk om if true faktisk er aktivt. Åpne Firebase Console → Firestore → Rules og søk etter if true. Finner du det noe sted utenfor en kommentar, har du et åpen-regel-funn. Rules-simulatoren i samme UI lar deg spille av angriperens request lokalt — lim inn en anonym GET /users/somebody og bekreft at simulatoren returnerer Allowed.

Ekstern bekreftelse: kjør en FixVibe-skanning mot produksjons-URL-en din. baas.firebase-rules-sjekken sonderer Firestore-, Realtime Database- og Storage-reglene dine og rapporterer det samme funnet som en angriper ville oppdaget — uavhengig av hva Firebase Console viser.

Ofte stilte spørsmål

Neste steg

Kjør en FixVibe-skanning mot produksjons-URL-en din — baas.firebase-rules-sjekken bekrefter om if true for øyeblikket kan utnyttes fra det offentlige internett. For skanner-mekanikken og parallelle deteksjoner for Realtime Database og Storage, se Firebase rules-skanner. For den tilsvarende klassen av feilkonfigurasjon på Supabase, les Supabase RLS-skanner.