Firebase-reëls-skandeerder: vind oop Firestore-, Realtime-Database- en Stoor-reëls

Hoe die skandeerder oop Firebase-reëls vind

Firebase-dienste stel bekende, voorspelbare URL-vorms bloot. 'n Skandeerder sonder geloofsbriewe kan elkeen ondersoek en waarneem of anonieme leesoperasies slaag. Die FixVibe baas.firebase-rules-toets loop in drie onafhanklike ondersoeke — een per Firebase-diens:

• <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. Die skandeerder ondersoek https://[project-id]-default-rtdb.firebaseio.com/.json. As die wortel anoniem leesbaar is, is die antwoord die hele databasisboom as JSON. 'n Meer konserwatiewe toets navraag .json?shallow=true, wat slegs top-vlak sleutels teruggee — 'n bevinding in elk geval.
• Cloud Storage. Die skandeerder vra https://firebasestorage.googleapis.com/v0/b/[project-id].appspot.com/o. As die antwoord lêername lys sonder autentisering, is die emmer anon-lysbaar. Lysbare stoorplek is 'n bevinding selfs wanneer individuele lêerafladings geweier word — aanvallers lys die emmer om raaibare lêername te vind.

Hoe die toets-modus-voetpistool werklik lyk

Firebase se quickstart-dokumentasie sluit een van die mees-gekopieerde reël-blokke op die internet in:

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

Firebase het voorheen 'n outomatiese 30-dae-verstryking op hierdie reëls bygevoeg. Dit het verander: vandag bly die reëls vir altyd in plek tensy die ontwikkelaar hulle vervang. KI-koderingsgereedskap — opgelei op jare se dokumentasie wat die toets-modus-blok insluit — stoot dit gereeld woordeliks uit en sê vir die ontwikkelaar "dit is jou sekuriteitsreël." Dit is nie.

Ander variante wat in produksie opduik maar net so toegeeflik is:

// 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;

• 'n Toekoms-tydstempel-variant: 'n reël wat alles toelaat tot 'n datum ver in die toekoms. Verloop nooit effektief nie (sien die uitgeligte blok hierbo).
• allow read: if true; allow write: if request.auth != null; — openbare leesoperasies, enige geautentiseerde gebruiker kan skryf.
• allow read, write: if request.auth != null; — enige aangetekende gebruiker kan enige dokument lees of skryf, insluitend ander gebruikers se data.

Wat om te doen wanneer die skandeerder 'n oop reël vind

Oop Firebase-reëls is 'n looptyd-noodgeval. Die regstelling is dieselfde vorm oor al drie dienste: beperk elke reël tot request.auth.uid teen 'n eksplisiete eienaar-veld. Elke diens het sy eie reël-sintaks:

Firestore

match /users/{userId} { allow read, write: if request.auth != null && request.auth.uid == userId; }. Die pad-segment-binding {userId} word die enigste dokument wat die gebruiker kan aanraak.

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; } } }. Konvensie: stoor lêers onder users/[uid]/[filename] en laat die pad eienaarskap afdwing.

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

Ontplooi reëls via die Firebase-CLI: firebase deploy --only firestore:rules, firebase deploy --only database, firebase deploy --only storage. Verifieer dat die nuwe reëls in produksie is deur die FixVibe-skandering weer uit te voer — die baas.firebase-rules-bevinding behoort verwyder te wees.

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

Hoe dit met Firebase se ingeboude gereedskap vergelyk

Firebase-Console wys jou die huidige reëls maar oudit hulle nie teen looptyd-gedrag nie. Die Firebase-Reëls-simulator laat jou reël-logika teen sintetiese versoeke toets — nuttig maar plaaslik. Geen van albei gereedskap vertel jou wat jou produksie-reëls werklik aan 'n anonieme aanvaller op die openbare internet teruggee nie. 'n Eksterne skandeerder soos FixVibe (of Burp Suite met handmatige konfigurasie) is die enigste ding wat vanaf dieselfde hoek ondersoek as wat 'n aanvaller sou. Google se eie App Check versag misbruik maar vervang nie korrek-omvattende reëls nie.

Algemene vrae

Volgende stappe

Voer 'n gratis FixVibe-skandering teen jou produksie-URL uit — die baas.firebase-rules-toets stuur op elke plan en merk oop reëls oor Firestore, Realtime Database en Cloud Storage. Vir 'n dieper verduideliking van die allow read, write: if true-patroon spesifiek, sien Firebase allow read, write: if true verduidelik. Vir die sambreel-oorsig oor Supabase, Firebase, Clerk en Auth0, lees BaaS-wankonfigurasieskandeerder.