Firebase-regelscanner: find åbne Firestore-, Realtime Database- og Storage-regler

Sådan finder scanneren åbne Firebase-regler

Firebase-tjenester eksponerer velkendte, forudsigelige URL-former. En scanner uden legitimationsoplysninger kan sondere hver enkelt og observere, om anonyme læsninger lykkes. FixVibes baas.firebase-rules-check kører i tre uafhængige sonderinger — én per Firebase-tjeneste:

• <strong>Firestore.</strong> The scanner extracts the project ID from the deployed app's bundle (it's in <code>firebase.initializeApp({ projectId: ... })</code>), then issues <code>GET https://firestore.googleapis.com/v1/projects/[project-id]/databases/(default)/documents/[collection]:listDocuments</code> against common collection names. A <code>200 OK</code> with documents in the response means <code>allow read</code> is permissive.
• Realtime Database. Scanneren sonderer https://[project-id]-default-rtdb.firebaseio.com/.json. Hvis roden er læsbar anonymt, er svaret hele databasetræet som JSON. En mere konservativ test forespørger .json?shallow=true, som returnerer kun topniveau-nøgler — et fund under alle omstændigheder.
• Cloud Storage. Scanneren forespørger https://firebasestorage.googleapis.com/v0/b/[project-id].appspot.com/o. Hvis svaret lister filnavne uden autentificering, er bucketen anon-listbar. Listbar storage er et fund, selv når individuelle fildownloads er nægtet — angribere opregner bucketen for at finde gættelige filnavne.

Hvordan test-mode-faldgruben faktisk ser ud

Firebase's quickstart-dokumentation inkluderer en af de mest kopierede regelblokke på internettet:

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

Firebase plejede at tilføje et automatisk 30-dages udløb på disse regler. Det ændrede sig: i dag består reglerne for evigt, medmindre udvikleren erstatter dem. AI-kodeværktøjer — der har trænet på år af dokumentation, der inkluderer test-mode-blokken — udsender den ofte ordret og fortæller udvikleren "dette er din sikkerhedsregel." Det er den ikke.

Andre varianter, der dukker op i produktion, men er lige så tilladende:

// future-date variant — equivalent to "if true"
allow read, write: if request.time < timestamp.date(2099, 1, 1);

// authenticated-user variant — any signed-in user reads and writes anything
allow read: if true;
allow write: if request.auth != null;

// any-auth variant — any signed-in user owns every document
allow read, write: if request.auth != null;

• En fremtidigt-tidsstempel-variant: en regel, der tillader alt indtil en dato langt ude i fremtiden. Udløber aldrig effektivt (se den fremhævede blok ovenfor).
• allow read: if true; allow write: if request.auth != null; — offentlige læsninger, enhver autentificeret bruger kan skrive.
• allow read, write: if request.auth != null; — enhver indlogget bruger kan læse eller skrive ethvert dokument, inklusive andre brugeres data.

Hvad man gør, når scanneren finder en åben regel

Åbne Firebase-regler er en runtime-nødsituation. Løsningen har samme form på tværs af alle tre tjenester: begræns hver regel til request.auth.uid mod et eksplicit ejer-felt. Hver tjeneste har sin egen regelsyntaks:

Firestore

match /users/{userId} { allow read, write: if request.auth != null && request.auth.uid == userId; }. Sti-segment-bindingen {userId} bliver det eneste dokument, brugeren kan røre.

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

Realtime Database

<code>{ "rules": { "users": { "$uid": { ".read": "$uid === auth.uid", ".write": "$uid === auth.uid" } } } }</code>. The <code>$uid</code> wildcard captures the path segment for comparison.

{
  "rules": {
    "users": {
      "$uid": {
        ".read":  "$uid === auth.uid",
        ".write": "$uid === auth.uid"
      }
    }
  }
}

Cloud Storage

service firebase.storage { match /b/{bucket}/o { match /users/{userId}/{allPaths=**} { allow read, write: if request.auth.uid == userId; } } }. Konvention: gem filer under users/[uid]/[filename], og lad stien håndhæve ejerskab.

service firebase.storage {
  match /b/{bucket}/o {
    match /users/{userId}/{allPaths=**} {
      allow read, write: if request.auth.uid == userId;
    }
  }
}

Deploy regler via Firebase CLI: firebase deploy --only firestore:rules, firebase deploy --only database, firebase deploy --only storage. Verificer, at de nye regler er i produktion, ved at køre FixVibe-scanningen igen — baas.firebase-rules-fundet bør forsvinde.

firebase deploy --only firestore:rules
firebase deploy --only database
firebase deploy --only storage

Hvordan dette sammenlignes med Firebase's indbyggede værktøjer

Firebase Console viser dig de aktuelle regler, men reviderer dem ikke mod runtime-adfærd. Firebase Rules-simulatoren lader dig teste regellogik mod syntetiske anmodninger — nyttig, men lokal. Ingen af værktøjerne fortæller dig, hvad dine produktionsregler faktisk returnerer til en anonym angriber på det offentlige internet. En ekstern scanner som FixVibe (eller Burp Suite med manuel konfiguration) er det eneste, der sonderer fra den samme vinkel, som en angriber ville. Googles egen App Check mindsker misbrug, men erstatter ikke korrekt afgrænsede regler.

Ofte stillede spørgsmål

Næste skridt

Kør en gratis FixVibe-scanning mod din produktions-URL — baas.firebase-rules-checken leveres på hver plan og markerer åbne regler på tværs af Firestore, Realtime Database og Cloud Storage. For en dybere forklaring af allow read, write: if true-mønsteret specifikt, se Firebase allow read, write: if true forklaret. For paraplyvisningen på tværs af Supabase, Firebase, Clerk og Auth0, læs BaaS-fejlkonfigurationsscanner.