Firebase rules-skanner: finn åpne regler i Firestore, Realtime Database og Storage

Hvordan skanneren finner åpne Firebase-regler

Firebase-tjenester eksponerer velkjente, forutsigbare URL-former. En skanner uten legitimasjon kan sondere hver enkelt og observere om anonyme lesinger lykkes. FixVibes baas.firebase-rules-sjekk kjører i tre uavhengige 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. Skanneren sonderer https://[project-id]-default-rtdb.firebaseio.com/.json. Hvis roten er anonymt lesbar, er svaret hele databasetreet som JSON. En mer konservativ test spør .json?shallow=true, som bare returnerer toppnivå-nøkler — uansett er det et funn.
• Cloud Storage. Skanneren spør https://firebasestorage.googleapis.com/v0/b/[project-id].appspot.com/o. Hvis svaret lister filnavn uten autentisering, er bucketen anon-listbar. Listbar lagring er et funn selv når individuelle filnedlastinger avvises — angripere enumerer bucketen for å finne gjettbare filnavn.

Hvordan test-mode-fotskuddet faktisk ser ut

Firebases hurtigstartsdokumentasjon inneholder en av de mest kopierte regelblokkene på internett:

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

Firebase pleide å legge til en automatisk 30-dagers utløpstid på disse reglene. Det er endret: i dag består reglene for alltid med mindre utvikleren erstatter dem. AI-kodeverktøy — trent på flere år med dokumentasjon som inkluderer test-mode-blokken — slipper den ofte ordrett og forteller utvikleren "dette er sikkerhetsregelen din." Det er det ikke.

Andre varianter som dukker opp i produksjon, men er like tillatende:

// 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 variant med fremtidig tidsstempel: en regel som tillater alt fram til en dato langt i fremtiden. Utløper aldri effektivt (se den uthevede blokken over).
• allow read: if true; allow write: if request.auth != null; — offentlige lesinger, enhver autentisert bruker kan skrive.
• allow read, write: if request.auth != null; — enhver innlogget bruker kan lese eller skrive et hvilket som helst dokument, inkludert andre brukeres data.

Hva du gjør når skanneren finner en åpen regel

Åpne Firebase-regler er en runtime-nødssituasjon. Fiksen har samme form på tvers av alle tre tjenestene: avgrens hver regel til request.auth.uid mot et eksplisitt eierfelt. 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} blir det eneste dokumentet brukeren 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; } } }. Konvensjon: lagre filer under users/[uid]/[filename] og la stien håndheve eierskap.

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. Verifiser at de nye reglene er i produksjon ved å kjøre FixVibe-skanningen på nytt — baas.firebase-rules-funnet skal forsvinne.

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

Hvordan dette sammenlignes med Firebases innebygde verktøy

Firebase Console viser deg de gjeldende reglene, men gransker dem ikke mot runtime-atferd. Firebase Rules-simulatoren lar deg teste regellogikk mot syntetiske requests — nyttig, men lokalt. Ingen av verktøyene forteller deg hva produksjonsreglene dine faktisk returnerer til en anonym angriper på det offentlige internett. En ekstern skanner som FixVibe (eller Burp Suite med manuell konfigurasjon) er det eneste som sonderer fra samme vinkel som en angriper ville. Googles egen App Check demper misbruk, men erstatter ikke korrekt avgrensede regler.

Ofte stilte spørsmål

Neste steg

Kjør en gratis FixVibe-skanning mot produksjons-URL-en din — baas.firebase-rules-sjekken er med på alle planer og flagger åpne regler på tvers av Firestore, Realtime Database og Cloud Storage. For en dypere forklaring spesifikt av allow read, write: if true-mønsteret, se Firebase allow read, write: if true forklart. For helhetsbildet på tvers av Supabase, Firebase, Clerk og Auth0, les BaaS-feilkonfigurasjonsskanner.