Firebase rules-scanner: hitta öppna regler i Firestore, Realtime Database och Storage

Hur scannern hittar öppna Firebase-regler

Firebase-tjänster exponerar välkända, förutsägbara URL-former. En scanner utan inloggningsuppgifter kan sondera var och en och observera om anonyma läsningar lyckas. FixVibes baas.firebase-rules-check körs i tre oberoende sonderingar — en per Firebase-tjänst:

• <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. Scannern sonderar https://[project-id]-default-rtdb.firebaseio.com/.json. Om roten är anonymt läsbar är svaret hela databasträdet som JSON. Ett mer konservativt test frågar .json?shallow=true, som bara returnerar top-level-nycklar — i båda fallen ett fynd.
• Cloud Storage. Scannern frågar https://firebasestorage.googleapis.com/v0/b/[project-id].appspot.com/o. Om svaret listar filnamn utan autentisering är bucketen anonymt listbar. Listbart storage är ett fynd även när enskilda filnedladdningar nekas — angripare räknar upp bucketen för att hitta gissningsbara filnamn.

Hur test-mode-fotskottet faktiskt ser ut

Firebases snabbstartsdokumentation innehåller ett av de mest kopierade regelblocken på internet:

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

Firebase brukade lägga till en automatisk 30-dagars förfallotid på dessa regler. Det har ändrats: idag persisterar reglerna för alltid om inte utvecklaren ersätter dem. AI-kodningsverktyg — tränade på flera år av dokumentation som inkluderar test-mode-blocket — släpper det ofta ordagrant och säger till utvecklaren "det här är din säkerhetsregel". Det är det inte.

Andra varianter som dyker upp i produktion men är lika tillåtande:

// 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 framtida tidsstämpel: en regel som tillåter allt fram till ett datum långt i framtiden. Förfaller aldrig effektivt (se det markerade blocket ovan).
• allow read: if true; allow write: if request.auth != null; — publika läsningar, vilken autentiserad användare som helst kan skriva.
• allow read, write: if request.auth != null; — vilken inloggad användare som helst kan läsa eller skriva vilket dokument som helst, inklusive andra användares data.

Vad du gör när scannern hittar en öppen regel

Öppna Firebase-regler är en runtime-nödsituation. Fixen har samma form över alla tre tjänsterna: begränsa varje regel till request.auth.uid mot ett explicit ägarfält. Varje tjänst har sin egen regelsyntax:

Firestore

match /users/{userId} { allow read, write: if request.auth != null && request.auth.uid == userId; }. Sökvägs-segment-bindningen {userId} blir det enda dokumentet användaren kan röra.

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: lagra filer under users/[uid]/[filename] och låt sökvägen tvinga fram ägarskap.

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

Deploya regler via Firebase CLI: firebase deploy --only firestore:rules, firebase deploy --only database, firebase deploy --only storage. Verifiera att de nya reglerna är i produktion genom att köra FixVibe-skanningen igen — baas.firebase-rules-fyndet ska försvinna.

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

Hur detta jämförs med Firebases inbyggda verktyg

Firebase-konsolen visar dig de aktuella reglerna men granskar dem inte mot runtime-beteende. Firebase Rules-simulatorn låter dig testa regel-logik mot syntetiska förfrågningar — användbart men lokalt. Inget av verktygen säger dig vad dina produktionsregler faktiskt returnerar till en anonym angripare på det publika internetet. En extern scanner som FixVibe (eller Burp Suite med manuell konfiguration) är det enda som sonderar från samma vinkel som en angripare skulle. Googles egen App Check mildrar missbruk men ersätter inte korrekt avgränsade regler.

Vanliga frågor

Nästa steg

Kör en gratis FixVibe-scanning mot din produktions-URL — baas.firebase-rules-checken ingår i varje plan och flaggar öppna regler över Firestore, Realtime Database och Cloud Storage. För en djupare förklaring specifikt av allow read, write: if true-mönstret, se Firebase allow read, write: if true förklarat. För helhetsbilden över Supabase, Firebase, Clerk och Auth0, läs BaaS-felkonfigurationsscanner.