Firebase-Rules-Scanner: offene Regeln in Firestore, Realtime Database und Storage finden

Wie der Scanner offene Firebase-Regeln findet

Firebase-Dienste exponieren wohlbekannte, vorhersagbare URL-Formen. Ein Scanner ohne Credentials kann jeden sondieren und beobachten, ob anonyme Lesezugriffe gelingen. Der baas.firebase-rules-Check von FixVibe läuft in drei unabhängigen Sondierungen — einer pro Firebase-Dienst:

• <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. Der Scanner sondiert https://[project-id]-default-rtdb.firebaseio.com/.json. Ist der Root anonym lesbar, ist die Antwort der komplette Datenbankbaum als JSON. Ein konservativerer Test fragt .json?shallow=true ab, das nur Top-Level-Keys liefert — in beiden Fällen ein Befund.
• Cloud Storage. Der Scanner fragt https://firebasestorage.googleapis.com/v0/b/[project-id].appspot.com/o ab. Listet die Antwort Dateinamen ohne Authentifizierung auf, ist der Bucket anonym auflistbar. Auflistbares Storage ist ein Befund, selbst wenn einzelne Datei-Downloads verweigert werden — Angreifer zählen den Bucket auf, um erratbare Dateinamen zu finden.

Wie der Test-Mode-Footgun tatsächlich aussieht

Die Quickstart-Dokumentation von Firebase enthält einen der am häufigsten kopierten Regelblöcke im Internet:

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

Firebase fügte diesen Regeln früher eine automatische 30-Tage-Ablaufzeit hinzu. Das hat sich geändert: heute persistieren die Regeln ewig, sofern der Entwickler sie nicht ersetzt. KI-Coding-Tools — trainiert auf jahrelanger Dokumentation, die den Test-Mode-Block enthält — geben ihn häufig wortwörtlich aus und sagen dem Entwickler „das ist deine Sicherheitsregel". Ist sie nicht.

Andere Varianten, die in Produktion auftauchen, aber genauso permissiv sind:

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

• Eine Variante mit zukünftigem Zeitstempel: eine Regel, die alles bis zu einem weit in der Zukunft liegenden Datum erlaubt. Läuft effektiv nie ab (siehe den hervorgehobenen Block oben).
• allow read: if true; allow write: if request.auth != null; — öffentliche Lesezugriffe, jeder authentifizierte Nutzer darf schreiben.
• allow read, write: if request.auth != null; — jeder angemeldete Nutzer kann jedes Dokument lesen oder schreiben, einschließlich der Daten anderer Nutzer.

Was zu tun ist, wenn der Scanner eine offene Regel findet

Offene Firebase-Regeln sind ein Runtime-Notfall. Der Fix hat in allen drei Diensten dieselbe Form: grenze jede Regel auf request.auth.uid gegen ein explizites Eigentümerfeld ein. Jeder Dienst hat seine eigene Regelsyntax:

Firestore

match /users/{userId} { allow read, write: if request.auth != null && request.auth.uid == userId; }. Die Pfad-Segment-Bindung {userId} wird zum einzigen Dokument, das der Nutzer berühren kann.

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: speichere Dateien unter users/[uid]/[filename] und lass den Pfad das Eigentum erzwingen.

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

Deploye Regeln über die Firebase-CLI: firebase deploy --only firestore:rules, firebase deploy --only database, firebase deploy --only storage. Verifiziere, dass die neuen Regeln in Produktion sind, indem du den FixVibe-Scan erneut laufen lässt — der baas.firebase-rules-Befund sollte verschwinden.

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

Wie sich das mit Firebases eingebauten Tools vergleicht

Die Firebase-Konsole zeigt dir die aktuellen Regeln, auditiert sie aber nicht gegen das Runtime-Verhalten. Der Firebase-Rules-Simulator lässt dich Regel-Logik gegen synthetische Requests testen — nützlich, aber lokal. Keines der beiden Tools sagt dir, was deine Produktionsregeln tatsächlich einem anonymen Angreifer im öffentlichen Internet zurückgeben. Ein externer Scanner wie FixVibe (oder Burp Suite mit manueller Konfiguration) ist das Einzige, was aus dem gleichen Winkel sondiert wie ein Angreifer. Googles eigener App Check mildert Missbrauch, ersetzt aber nicht korrekt eingegrenzte Regeln.

Häufig gestellte Fragen

Nächste Schritte

Lass einen kostenlosen FixVibe-Scan gegen deine Produktions-URL laufen — der baas.firebase-rules-Check ist in jedem Tarif und markiert offene Regeln über Firestore, Realtime Database und Cloud Storage. Für eine tiefere Erklärung speziell zum allow read, write: if true-Muster siehe Firebase allow read, write: if true erklärt. Für den Gesamtüberblick über Supabase, Firebase, Clerk und Auth0 lies BaaS-Fehlkonfigurations-Scanner.