Firebase allow read, write: if true forklaret: hvad det gør, og hvordan man retter det

Syntaksen, linje for linje

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

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

Afkodet:

• rules_version = '2'; vælger v2-regelmotoren (aktuel). Ældre v1-regler er udfasede.
• service cloud.firestore afgrænser blokken til Firestore. Realtime Database bruger en anden JSON-baseret syntaks; Cloud Storage bruger service firebase.storage.
• match /databases/{database}/documents binder den specielle (default)-database (de fleste projekter har kun én).
• match /{document=**} er et rekursivt wildcard. ** matcher enhver sti af enhver dybde. Kombineret med {document}, fanger dette hvert dokument i hver samling — en enkelt match-klausul, der styrer hele databasen.
• allow read, write: if true; er regelbodyen. Både read og write er tilladt; betingelsen if true er, ja, altid sand. read dækker get- og list-operationer; write dækker create, update og delete.

Netto-effekt: enhver klient med Firebase-projekt-ID'et og den rigtige SDK kan læse eller skrive ethvert dokument i enhver samling. Autentificering kræves ikke. Hastighedsgrænser håndhæves ikke.

Hvorfor Firebase leverer dette som standard

Firebase vil have dig til at kode i de første 30 sekunder efter at have oprettet et projekt. Alternativet — at få dig til at skrive en korrekt regel, før nogen læsning eller skrivning virker — ville blokere onboarding. Så Console tilbyder to muligheder, når du opretter en database: Production mode (afvis alt, du skriver reglerne) eller Test mode (tillad alt i 30 dage). De fleste udviklere klikker på test-mode og glemmer derefter at vende tilbage. Ældre projekter havde 30-dages timeren; aktuelle projekter har en ubegrænset if true-regel uden automatisk udløb.

Det strukturelle problem: AI-kodeværktøjer træner på dokumentation, tutorials og Stack Overflow-svar, der viser test-mode-regler. Når du beder Cursor eller Claude Code om "hvordan sætter jeg Firebase op," inkluderer svaret ofte præcis allow read, write: if true-blokken, som om det var produktionsreglen. AI'en ved ikke — og bliver ikke promptet til at vide — at denne regel ikke er sikker til produktion.

Hvad en angriber ser

Konkret kan en angriber, der kender dit Firebase-projekt-ID (kan udtrækkes fra enhver deployet apps bundt på 30 sekunder), og som kører følgende, liste hvert dokument i hver samling:

En enkelt uautentificeret curl-anmodning er nok til at opregne hver samling. Se den fremhævede blok 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 fulde liste over topniveau-samlinger. For hver samling returnerer en anden anmodning dokumenter. Der er ingen hastighedsgrænse på denne sti, fordi if true-regler accepterer anonym trafik. Vi har set Firebase-databaser med millioner af dokumenter opregnet på under en time.

På skrivestien: en enkelt POST med {fields} opretter et nyt dokument. Angribere kan forurene dine samlinger med affald, hærge brugervendte sider, der læser fra Firestore, eller bruge din database som en gratis beskedmægler — din brugsregning stiger, du undersøger, regningen forklarer problemet.

Fire produktionssikre erstatninger

Vælg den erstatning, der matcher din apps datamodel. Alle fire antager, at du har brugerautentificering (Firebase Auth eller enhver udbyder, der udsteder et Firebase ID-token):

Mulighed 1: Brugerejede dokumenter

Mest almindelige SaaS-mønster. Dokumenter lever under /users/{userId}/..., og kun ejeren 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;
}

Mulighed 2: Ejer-felt på hvert dokument

Når dokumenter lever i flade samlinger (ikke indlejret under bruger-ID), gem et owner_uid-felt og tjek 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;
}

Mulighed 3: Multi-tenant org-isolation

For B2B SaaS med org-afgrænset data. Gem et org_id-felt på hvert dokument, og tjek det mod brugerens custom claim. allow read, write: if request.auth.token.org_id == resource.data.org_id;. Kræver, at custom claim sættes under tilmelding via Firebase Admin SDK.

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

Mulighed 4: Læseligt offentligt indhold

Til marketingindhold, offentlige profiler, produktkataloger — alt, der ægte er offentligt-læs, men admin-kun-skriv. match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }. admin-custom claim sættes kun på admin-konti.

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

Hurtig revisionsforespørgsel

Før du retter, tjek om if true faktisk er live. Åbn Firebase Console → Firestore → Rules og søg efter if true. Hvis du finder det nogen steder uden for en kommentar, har du et åben-regel-fund. Rules-simulatoren i den samme UI lader dig genspille angriberens anmodning lokalt — indsæt en anonym GET /users/somebody, og bekræft, at simulatoren returnerer Allowed.

Ekstern bekræftelse: kør en FixVibe-scanning mod din produktions-URL. baas.firebase-rules-checken sonderer dine Firestore-, Realtime Database- og Storage-regler og rapporterer det samme fund, som en angriber ville opdage — uafhængigt af, hvad Firebase Console viser.

Ofte stillede spørgsmål

Næste skridt

Kør en FixVibe-scanning mod din produktions-URL — baas.firebase-rules-checken bekræfter, om if true aktuelt er udnytteligt fra det offentlige internet. For scannermekanikken og de parallelle detektioner for Realtime Database og Storage, se Firebase-regelscanner. For den tilsvarende klasse af fejlkonfiguration på Supabase, læs Supabase RLS-scanner.