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

Wie der Scanner offene Firebase-Regeln findet

Firebase services are reachable at predictable public addresses, so a scanner with no credentials can check each one the way an anonymous visitor would. FixVibe's Firebase check covers all three services independently:

• Firestore. FixVibe finds the project from the deployed app's own Firebase configuration and reports collections that anonymous visitors can read.
• Realtime Database. FixVibe reports a database whose data anonymous visitors can read — often the whole tree at once.
• Cloud Storage. FixVibe reports buckets that anonymous visitors can list. Listable storage is a finding even when individual downloads are denied, because it lets attackers find guessable filenames.

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

Echtzeitdatenbank

{ "rules": { "users": { "$uid": { ".read": "$uid === auth.uid", ".write": "$uid === auth.uid" } } } }. Der $uid-Wildcard erfasst das Pfadsegment für den Vergleich.

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

Cloud-Speicher

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

Deploy rules via the Firebase CLI: firebase deploy --only firestore:rules, firebase deploy --only database, firebase deploy --only storage. Verify the new rules are in production by re-running the FixVibe scan — the open-rules finding should clear.

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

Run a free FixVibe scan against your production URL — the Firebase rules check runs on every plan and flags open rules across Firestore, Realtime Database, and Cloud Storage. For a deeper explainer on the allow read, write: if true pattern specifically, see Firebase allow read, write: if true explained. For the umbrella view across Supabase, Firebase, Clerk, and Auth0, read BaaS misconfiguration scanner.