Firebase Security Rules: Beispiele

Q: Wie viele get()-Aufrufe darf eine Rule machen?

Firebase dokumentiert ein Limit von 10 Dokumentzugriffen für Anfragen auf einzelne Dokumente und Abfragen sowie 20 für Lesevorgänge über mehrere Dokumente, Transaktionen und Batch-Schreibvorgänge. Wer darüber liegt, bekommt einen permission denied Fehler.

Q: Gelten Security Rules für meinen Server-Code?

Nein. Rules schützen Anfragen von Mobil- und Web-Clients. Firebase gibt an, dass die Server-Client-Bibliotheken alle Cloud Firestore Security Rules umgehen, prüfe Eingaben in deinem Server-Code also separat.

Q: Wie teste ich Rules, ohne Live-Daten anzufassen?

Starte den Emulator mit firebase emulators:start --only firestore und schreib dann Tests mit dem Paket @firebase/rules-unit-testing, mit assertSucceeds und assertFails für erlaubte und blockierte Aktionen.

Firebase Security Rules Beispiele: Firestore, Storage, RTDB | We.Inc

Firebase Security Rules zum Kopieren für Daten nur für Besitzer, öffentliches Lesen, Admin-Rollen und Validierung in Firestore, Storage und Realtime Database, dazu wie du sie testest.

Firebase Security Rules: Beispiele

Firebase Security Rules legen fest, wer welche Daten in deiner App lesen und schreiben darf. Beginne jede Firestore-Datei mit rules_version = '2', erlaube Zugriff nur, wenn request.auth gesetzt ist, vergleiche request.auth.uid mit dem Besitzer des Dokuments und prüfe eingehende Felder mit request.resource.data. Teste mit dem Emulator, bevor du deployst.

Die Variablen, die du in jedem Produkt am häufigsten nutzt

Produkt
Angemeldeter Nutzer
Daten, die geschrieben werden

Cloud Firestore

Cloud Storage
request.resource (size, contentType)

Realtime Database
newData

Wenn deine App, dein Shop oder dein Mitgliederbereich Daten in Firebase speichert, sind die Rules das Einzige, was zwischen den Datensätzen deiner Kunden und jedem steht, der die öffentliche Konfiguration deines Projekts kennt. Die Rezepte unten decken die Fälle ab, die die meisten kleinen Apps brauchen. Filtere nach Produkt, kopiere eines und passe die Collection-Namen an deine an.

Wähle das Rezept, das zu deinem Fall passt, und kopiere es in deine Rules-Datei.
Benenne die Collection- oder Pfadnamen wie users oder orders passend zu deiner Datenbank um.
Führe die Rules in der Local Emulator Suite aus und probiere sowohl erlaubte als auch blockierte Anfragen.
Deploye mit der Firebase CLI oder veröffentliche in der Konsole, sobald die Tests bestehen.

Rules sind keine Filter. Eine Abfrage nach Dokumenten, die der Nutzer nicht lesen darf, wird komplett abgelehnt, schreib deine Abfragen also passend zu deinen Rules.
Jeder Aufruf von get() oder exists() in einer Rule wird als Dokument-Lesevorgang abgerechnet, auch wenn die Anfrage abgelehnt wird, halte Lookups also sparsam.
Sperre Felder, die Nutzer nie ändern dürfen, etwa eine Besitzer-ID oder eine Rolle, indem du request.resource.data mit resource.data vergleichst.
Durchsuche deine Rules vor dem Launch nach if true. Firebase warnt ausdrücklich davor, Rules, die alles erlauben, in Produktion zu nutzen.

Häufige Fragen

Was ist der Firestore-Testmodus?

Eine der beiden Startoptionen beim Anlegen einer Datenbank. Firebase beschreibt den Testmodus als gut für den Einstieg, sagt aber, dass er jedem erlaubt, deine Daten zu lesen und zu überschreiben. Der Produktionsmodus verweigert alle Lese- und Schreibzugriffe von Mobil- und Web-Clients, bis du Rules schreibst.

Warum bekommt meine App plötzlich Fehler wegen fehlender Berechtigung?

Such nach einer Bedingung, die request.time mit einem festen Datum vergleicht, etwa request.time < timestamp.date(2026, 11, 1). Sobald dieses Datum vorbei ist, schlägt jede Anfrage fehl. Ersetze sie durch echte Rules, statt das Datum zu verschieben.

Wie viele get()-Aufrufe darf eine Rule machen?

Firebase dokumentiert ein Limit von 10 Dokumentzugriffen für Anfragen auf einzelne Dokumente und Abfragen sowie 20 für Lesevorgänge über mehrere Dokumente, Transaktionen und Batch-Schreibvorgänge. Wer darüber liegt, bekommt einen permission denied Fehler.

Gelten Security Rules für meinen Server-Code?

Nein. Rules schützen Anfragen von Mobil- und Web-Clients. Firebase gibt an, dass die Server-Client-Bibliotheken alle Cloud Firestore Security Rules umgehen, prüfe Eingaben in deinem Server-Code also separat.

Wie teste ich Rules, ohne Live-Daten anzufassen?

Starte den Emulator mit firebase emulators:start --only firestore und schreib dann Tests mit dem Paket @firebase/rules-unit-testing, mit assertSucceeds und assertFails für erlaubte und blockierte Aktionen.

Wie eine Rule gelesen wird

Ein match-Block nennt einen Pfad, und die allow-Zeilen darin nennen die Aktionen wie read, create, update und delete, mit einer Bedingung nach if. Zugriff wird gewährt, wenn irgendeine passende allow-Zeile wahr ist; eine deny-Anweisung gibt es nicht.
resource.data ist das Dokument, wie es jetzt existiert, und request.resource.data ist, wie es nach dem Schreiben aussähe. Durch den Vergleich der beiden verhinderst du, dass jemand ein Feld ändert, das er nicht anfassen darf.

Rollen ohne Backend

Ein gängiges Muster speichert ein role-Feld in jedem Nutzerdokument und liest es in anderen Rules mit get(). Stell sicher, dass Nutzer ihre eigene Rolle nicht bearbeiten können, sonst könnte sich jeder selbst zum Admin machen.
Eine Alternative sind Custom Claims im Anmelde-Token, die aus Server-Code gesetzt und als request.auth.token gelesen werden. Das kostet keine zusätzlichen Dokument-Lesevorgänge.

Rules, die du vor dem Launch entfernen solltest

Diese Muster tauchen in Starter-Projekten und Tutorials auf. Jedes davon lässt Daten offen.

Riskante Rules und sicherere Alternativen

Riskante Rule
Warum sie ein Problem ist
Ersetzen durch

allow read, write: if true;
Jeder kann alles lesen oder überschreiben
Prüfungen auf Besitzer oder Rolle

allow read, write: if request.time < timestamp.date(...);
Bis zum Datum weit offen, danach geht alles kaputt
Echte Rules pro Collection

allow read, write: if request.auth != null;
Jeder angemeldete Fremde kann die Daten jedes Nutzers bearbeiten
request.auth.uid mit dem Besitzer vergleichen

Rules mit dem Emulator testen

Starte den Firestore-Emulator und prüfe dann, dass der Besitzer schreiben kann und ein Fremder nicht.

Rules-Unit-Test mit @firebase/rules-unit-testing

Nutzt eine Demo-Projekt-ID, damit nichts eine Live-Datenbank erreicht. Führe ihn aus, während firebase emulators:start --only firestore läuft.

Profile nur für Besitzer

Jeder Nutzer liest und bearbeitet nur das Dokument, dessen ID seiner Nutzer-ID entspricht.

Öffentlich lesen, Admin schreibt

Jeder kann den Produktkatalog lesen; nur Nutzer, deren Profil die Rolle admin hat, können ihn ändern.

Neue Bestellungen validieren

Ein Kunde kann eine Bestellung nur für sich selbst anlegen, mit positiver Summe und bekanntem Status, und sie danach nicht mehr bearbeiten.

Nutzer können ihre eigene Rolle nicht ändern

Profiländerungen sind nur erlaubt, wenn das role-Feld genau so bleibt, wie es war.

Nutzer laden eigene Bilder unter 5MB hoch

Dateien liegen im Ordner des jeweiligen Nutzers; Uploads müssen Bilder unter 5MB sein, und jeder Angemeldete kann sie ansehen.

Daten nur für Besitzer mit Validierung

Realtime Database Rules sind JSON. $uid erfasst den Schlüssel; newData ist der Wert, der geschrieben wird.

Rule-Rezepte

Rezepte anzeigen für

Alle Produkte

Cloud Firestore

Cloud Storage

Realtime Database

{n} Rezepte angezeigt

Kostenlos starten · Keine Kreditkarte nötig

Verwandt: Ratgeber

Produkt

Für wen

Funktionen

Ressourcen

Unternehmen

Sitemap