// docs / baas security / firebase if-true explainer

Firebase allow read, write: if true erklärt: was es tut und wie man es behebt

Q: Was ist der Unterschied zwischen if true und if request.auth != null ?

if true erlaubt anonymen Zugriff — jeden im Internet. if request.auth != null verlangt einen beliebigen angemeldeten Nutzer, was besser, aber immer noch falsch ist: jeder Nutzer deiner App kann die Daten jedes anderen Nutzers lesen. Produktionsregeln müssen auf den konkreten Nutzer oder die Org eingegrenzt sein, über request.auth.uid == resource.data.owner_uid oder ähnliches.

Q: Lässt Firebase if true -Regeln je automatisch ablaufen?

Ältere Projekte (vor 2023) hatten einen 30-Tage-Timer, der if true-Regeln in if false umwandelte. Aktuelle Projekte nicht — die Regel persistiert unbefristet, bis sie manuell ersetzt wird. Wenn du dein Projekt vor 2023 angelegt hast und deine Regeln gut aussehen, prüfe zweimal: der Timer könnte sie bereits auf if false gekippt haben, was deine eigene App blockiert.

Q: Was, wenn meine App echt öffentlich-lesbar ist (Blog, Produktkatalog)?

Dann schreibe explizit allow read: if true; allow write: if false; nur auf der öffentlichen Collection — nicht auf jeder Collection in deiner Datenbank. Verwende eine separate match-Klausel pro Collection und nie den rekursiven '{'document=**'}'-Wildcard auf schreibbaren Regeln.

<code>allow read, write: if true;</code> ist die mit Abstand häufigste Firebase-Fehlkonfiguration in Produktion. Es ist der Test-Mode-Default, den die Firebase-Konsole vorschlägt, wenn du eine neue Datenbank anlegst, die Regel, die KI-Coding-Tools aus der Dokumentation regenerieren, und die Regel, die deine gesamte Firestore-Datenbank für jeden im Internet öffnet. Dieser Artikel erklärt die Syntax präzise, zeigt, was ein Angreifer sieht, wenn diese Regel aktiv ist, und gibt dir vier progressiv strengere Ersetzungen für verschiedene Anwendungsfälle.

Die Syntax, Zeile für Zeile

Ein komplettes Firestore-Test-Mode-Regeldokument ist sechs Zeilen lang:

firebase

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

Dekodiert:

rules_version = '2'; wählt die v2-Regel-Engine (aktuell). Ältere v1-Regeln sind deprecated.
service cloud.firestore grenzt den Block auf Firestore ein. Realtime Database nutzt eine andere JSON-basierte Syntax; Cloud Storage nutzt service firebase.storage.
match /databases/{database}/documents bindet die spezielle (default)-Datenbank (die meisten Projekte haben nur eine).
match /{document=**} ist ein rekursiver Wildcard. Das ** matched jeden Pfad jeder Tiefe. Kombiniert mit {document} erfasst dies jedes Dokument in jeder Collection — eine einzige Match-Klausel, die die gesamte Datenbank regiert.
allow read, write: if true; ist der Regelkörper. Sowohl read als auch write sind erlaubt; die Bedingung if true ist eben immer wahr. read deckt get- und list-Operationen ab; write deckt create, update und delete ab.

Nettoeffekt: jeder Client mit der Firebase-Projekt-ID und dem richtigen SDK kann jedes Dokument in jeder Collection lesen oder schreiben. Authentifizierung wird nicht verlangt. Rate-Limits werden nicht erzwungen.

Warum Firebase das als Default mitliefert

Firebase will, dass du in den ersten 30 Sekunden nach Projektanlage codest. Die Alternative — dich zu zwingen, vor jedem Lese- oder Schreibzugriff eine korrekte Regel zu schreiben — würde das Onboarding blockieren. Also bietet die Konsole bei der Datenbankanlage zwei Optionen: Production mode (alles verweigern, du schreibst die Regeln) oder Test mode (alles für 30 Tage erlauben). Die meisten Entwickler klicken Test mode und vergessen es dann zu revidieren. Ältere Projekte hatten den 30-Tage-Timer; aktuelle Projekte haben eine unbefristete if true-Regel ohne automatischen Ablauf.

Das strukturelle Problem: KI-Coding-Tools trainieren auf Dokumentation, Tutorials und Stack-Overflow-Antworten, die Test-Mode-Regeln zeigen. Wenn du Cursor oder Claude Code fragst „wie richte ich Firebase ein", enthält die Antwort oft den exakten allow read, write: if true-Block, als wäre er die Produktionsregel. Die KI weiß nicht — und wird nicht angeleitet, es zu wissen — dass diese Regel für Produktion nicht sicher ist.

Was ein Angreifer sieht

Konkret kann ein Angreifer, der deine Firebase-Projekt-ID kennt (in 30 Sekunden aus dem Bundle einer deployten App extrahierbar) und Folgendes ausführt, jedes Dokument in jeder Collection auflisten:

Ein einziger nicht authentifizierter curl-Request reicht, um jede Collection aufzuzählen. Siehe den hervorgehobenen Block unten.

bash

curl 'https://firestore.googleapis.com/v1/projects/[project-id]/databases/(default)/documents:listCollectionIds' \
  -X POST \
  -H 'Content-Type: application/json' \
  -d '{}'

Die Antwort ist die vollständige Liste der Top-Level-Collections. Für jede Collection liefert ein zweiter Request Dokumente. Es gibt keine Rate-Limits auf diesem Pfad, weil if true-Regeln anonymen Traffic akzeptieren. Wir haben Firebase-Datenbanken mit Millionen von Dokumenten gesehen, die in unter einer Stunde aufgezählt wurden.

Auf dem Schreibpfad: ein einziger POST mit {fields} erzeugt ein neues Dokument. Angreifer können deine Collections mit Müll verschmutzen, nutzerseitige Seiten, die aus Firestore lesen, verunstalten oder deine Datenbank als kostenlosen Message-Broker nutzen — deine Nutzungsrechnung explodiert, du untersuchst, die Rechnung erklärt das Problem.

Vier produktionssichere Ersetzungen

Wähle die Ersetzung, die zum Datenmodell deiner App passt. Alle vier setzen voraus, dass du Nutzerauthentifizierung hast (Firebase Auth oder ein beliebiger Anbieter, der ein Firebase-ID-Token ausstellt):

Option 1: Nutzer-eigene Dokumente

Häufigstes SaaS-Muster. Dokumente leben unter /users/{userId}/... und nur der Eigentümer kann sie anfassen. match /users/{userId}/{document=**} { allow read, write: if request.auth != null && request.auth.uid == userId; }

firebase

match /users/{userId}/{document=**} {
  allow read, write: if request.auth != null
                     && request.auth.uid == userId;
}

Option 2: Eigentümerfeld auf jedem Dokument

Wenn Dokumente in flachen Collections leben (nicht unter Nutzer-ID verschachtelt), speichere ein owner_uid-Feld und prüfe es. match /posts/{postId} { allow read: if resource.data.public == true || resource.data.owner_uid == request.auth.uid; allow write: if request.auth.uid == resource.data.owner_uid; }

firebase

match /posts/{postId} {
  allow read:  if resource.data.public == true
              || resource.data.owner_uid == request.auth.uid;
  allow write: if request.auth.uid == resource.data.owner_uid;
}

Option 3: Multi-Tenant-Org-Isolation

Für B2B-SaaS mit org-eingegrenzten Daten. Speichere ein org_id-Feld auf jedem Dokument und prüfe es gegen den Custom-Claim des Nutzers. allow read, write: if request.auth.token.org_id == resource.data.org_id;. Erfordert das Setzen des Custom-Claims während der Anmeldung über das Firebase Admin SDK.

firebase

allow read, write: if request.auth.token.org_id == resource.data.org_id;

Option 4: Nur-Lese öffentlicher Inhalt

Für Marketing-Inhalte, öffentliche Profile, Produktkataloge — alles, was echt öffentlich lesbar, aber nur durch Admins schreibbar ist. match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }. Der admin-Custom-Claim wird nur auf Admin-Konten gesetzt.

firebase

match /products/{productId} {
  allow read:  if true;
  allow write: if request.auth.token.admin == true;
}

Schnelle Audit-Query

Bevor du korrigierst, prüfe, ob if true tatsächlich aktiv ist. Öffne Firebase-Konsole → Firestore → Rules und suche nach if true. Findest du es irgendwo außerhalb eines Kommentars, hast du einen offenen-Regel-Befund. Der Rules-Simulator in derselben UI lässt dich den Request des Angreifers lokal nachspielen — füge einen anonymen GET /users/somebody ein und bestätige, dass der Simulator Allowed zurückgibt.

Externe Bestätigung: lass einen FixVibe-Scan gegen deine Produktions-URL laufen. Der baas.firebase-rules-Check sondiert deine Firestore-, Realtime-Database- und Storage-Regeln und meldet denselben Befund, den ein Angreifer entdecken würde — unabhängig davon, was die Firebase-Konsole zeigt.

Häufig gestellte Fragen

Was ist der Unterschied zwischen <code>if true</code> und <code>if request.auth != null</code>?

if true erlaubt anonymen Zugriff — jeden im Internet. if request.auth != null verlangt einen beliebigen angemeldeten Nutzer, was besser, aber immer noch falsch ist: jeder Nutzer deiner App kann die Daten jedes anderen Nutzers lesen. Produktionsregeln müssen auf den konkreten Nutzer oder die Org eingegrenzt sein, über request.auth.uid == resource.data.owner_uid oder ähnliches.

Lässt Firebase <code>if true</code>-Regeln je automatisch ablaufen?

Ältere Projekte (vor 2023) hatten einen 30-Tage-Timer, der if true-Regeln in if false umwandelte. Aktuelle Projekte nicht — die Regel persistiert unbefristet, bis sie manuell ersetzt wird. Wenn du dein Projekt vor 2023 angelegt hast und deine Regeln gut aussehen, prüfe zweimal: der Timer könnte sie bereits auf if false gekippt haben, was deine eigene App blockiert.

Kann ich eine Zeitstempelprüfung mit zukünftigem Datum als Sicherheitsnetz verwenden?

Nein — eine Zeitstempel-Bedingung ist keine Sicherheitskontrolle. Sie lässt die offene Regel an einem zukünftigen Datum ablaufen, was bedeutet, dass Angreifer bis zu diesem Datum vollen Zugriff haben. Und du wirst das Datum vergessen. Ersetze if true durch eine auth-eingegrenzte Regel, nicht eine zeitbegrenzte.

Was, wenn meine App echt öffentlich-lesbar ist (Blog, Produktkatalog)?

Dann schreibe explizit allow read: if true; allow write: if false; nur auf der öffentlichen Collection — nicht auf jeder Collection in deiner Datenbank. Verwende eine separate match-Klausel pro Collection und nie den rekursiven {document=**}-Wildcard auf schreibbaren Regeln.

Nächste Schritte

Lass einen FixVibe-Scan gegen deine Produktions-URL laufen — der baas.firebase-rules-Check bestätigt, ob if true aktuell aus dem öffentlichen Internet ausgenutzt werden kann. Für die Scanner-Mechanik und die parallelen Detektionen für Realtime Database und Storage siehe Firebase-Rules-Scanner. Für die äquivalente Fehlkonfigurationsklasse in Supabase lies Supabase-RLS-Scanner.