Funktionsweise von Sicherheitsregeln

Sicherheit kann einer der komplexesten Aspekte der App-Entwicklung sein. In den meisten Anwendungen müssen Entwickler einen Server erstellen und ausführen, der die Authentifizierung (wer ein Nutzer ist) und die Autorisierung (was ein Nutzer tun kann) übernimmt.

Firebase Security Rules – Die mittlere (Server-)Ebene wird entfernt und Sie können pfadbasierte Berechtigungen für Clients festlegen, die direkt eine Verbindung zu Ihren Daten herstellen. In dieser Anleitung erfahren Sie mehr darüber, wie Regeln auf eingehende Anfragen angewendet werden.

Wählen Sie ein Produkt aus, um mehr über die entsprechenden Regeln zu erfahren.

Cloud Firestore

Grundstruktur

Firebase Security Rules in Cloud Firestore und Cloud Storage verwenden die folgende Struktur und Syntax:

service <<name>> {
  // Match the resource path.
  match <<path>> {
    // Allow the request if the following conditions are true.
    allow <<methods>> : if <<condition>>
  }
}

Die folgenden Schlüsselkonzepte sind wichtig, wenn Sie die Regeln erstellen:

  • Anfrage:Die Methode oder Methoden, die in der allow-Anweisung aufgerufen werden. Dies sind die Methoden, die ausgeführt werden dürfen. Die Standardmethoden sind get, list, create, update und delete. Die Convenience-Methoden read und write ermöglichen einen umfassenden Lese- und Schreibzugriff auf die angegebene Datenbank oder den angegebenen Speicherpfad.
  • Pfad:Der Datenbank- oder Speicherort, dargestellt als URI-Pfad.
  • Regel:Die allow-Anweisung, die eine Bedingung enthält, die eine Anfrage zulässt, wenn sie als „true“ ausgewertet wird.

Sicherheitsregeln Version 2

Seit Mai 2019 ist Version 2 der Firebase-Sicherheitsregeln verfügbar. In Version 2 der Sicherheitsregeln wird das Verhalten von rekursiven Platzhaltern {name=**} verändert. Sie müssen Version 2 verwenden, wenn Sie Sammlungsgruppenabfragen verwenden möchten. Sie müssen Version 2 aktivieren, indem Sie rules_version = '2'; als erste Zeile in Ihren Sicherheitsregeln festlegen:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {

Übereinstimmende Pfade

Alle Match-Anweisungen sollten auf Dokumente und nicht auf Sammlungen verweisen. Eine Match-Anweisung kann auf ein bestimmtes Dokument verweisen, z. B. in match /cities/SF, oder Platzhalter verwenden, um auf ein beliebiges Dokument im angegebenen Pfad zu verweisen, z. B. in match /cities/{city}.

In dem Beispiel verwendet die Match-Anweisung die Platzhaltersyntax {city}. Das bedeutet, dass die Regel für alle Dokumente in der Sammlung cities gilt, z. B. für /cities/SF oder /cities/NYC . Wenn die allow-Ausdrücke in der Match-Anweisung ausgewertet werden, wird die city-Variable in den Namen des Stadtdokuments aufgelöst, z. B. SF oder NYC .

Passende Untersammlungen

Daten in Cloud Firestore sind in Sammlungen von Dokumenten organisiert. Jedes Dokument kann die entsprechende Hierarchie durch untergeordnete Sammlungen (Untersammlungen) erweitern. Für die Nutzung der Hierarchie ist es wichtig zu verstehen, wie Sicherheitsregeln mit hierarchischen Daten interagieren.

Betrachten Sie die Situation, in der jedes Dokument in der Sammlung cities eine Untersammlung landmarks enthält. Sicherheitsregeln gelten nur für den übereinstimmenden Pfad. Daher gelten die in der Sammlung cities definierten Zugriffssteuerungen nicht für die Untersammlung landmarks. Um den Zugriff auf untergeordnete Sammlungen zu steuern, müssen Sie stattdessen explizite Regeln schreiben:

service cloud.firestore {
  match /databases/{database}/documents {
    match /cities/{city} {
      allow read, write: if <condition>;

      // Explicitly define rules for the 'landmarks' subcollection
      match /landmarks/{landmark} {
        allow read, write: if <condition>;
      }
    }
  }
}

Beim Verschachteln von match-Anweisungen bezieht sich der Pfad der inneren match-Anweisung immer auf den Pfad der äußeren match-Anweisung. Die folgenden Regelsätze sind daher äquivalent:

service cloud.firestore {
  match /databases/{database}/documents {
    match /cities/{city} {
      match /landmarks/{landmark} {
        allow read, write: if <condition>;
      }
    }
  }
}

service cloud.firestore {
  match /databases/{database}/documents {
    match /cities/{city}/landmarks/{landmark} {
      allow read, write: if <condition>;
    }
  }
}

Überlappende Match-Anweisungen

Es ist möglich, dass ein Dokument mit mehr als einer match-Anweisung übereinstimmt. Falls mehrere allow-Ausdrücke mit einer Anfrage übereinstimmen, wird der Zugriff erlaubt, wenneine der Bedingungen true ist:

service cloud.firestore {
  match /databases/{database}/documents {
    // Matches any document in the 'cities' collection.
    match /cities/{city} {
      allow read, write: if false;
    }

    // Matches any document in the 'cities' collection.
    match /cities/{document} {
      allow read, write: if true;
    }
  }
}

Im Beispiel werden alle Lese- und Schreibzugriffe auf die Sammlung cities erlaubt, weil die zweite Regel immer true ist, obwohl die erste Regel immer false ist.

Rekursive Platzhalter

Wenn Regeln auf eine beliebig tiefe Hierarchie angewendet werden sollen, verwenden Sie die rekursive Platzhaltersyntax {name=**}:

service cloud.firestore {
  match /databases/{database}/documents {
    // Matches any document in the cities collection as well as any document
    // in a subcollection.
    match /cities/{document=**} {
      allow read, write: if <condition>;
    }
  }
}

Bei Verwendung der rekursiven Platzhaltersyntax enthält die Platzhaltervariable das gesamte übereinstimmende Pfadsegment, auch wenn sich das Dokument in einer tief verschachtelten Untersammlung befindet. Die oben aufgeführten Regeln würden beispielsweise mit einem Dokument unter /cities/SF/landmarks/coit_tower übereinstimmen und der Wert der document-Variable wäre SF/landmarks/coit_tower.

Beachten Sie jedoch, dass das Verhalten rekursiver Platzhalter von der Regelversion abhängt.

Version 1

Sicherheitsregeln verwenden standardmäßig Version 1. In Version 1 entsprechen rekursive Platzhalter einem oder mehreren Pfadelementen. Sie stimmen nicht mit einem leeren Pfad überein. match /cities/{city}/{document=**} entspricht also Dokumenten in Untersammlungen, aber nicht mit Dokumenten in der Sammlung cities überein. Dagegen stimmt match /cities/{document=**} mit beiden Dokumenten in der Sammlung cities und mit Untersammlungen überein.

Rekursive Platzhalter müssen am Ende einer Match-Anweisung stehen.

Version 2

In Version 2 der Sicherheitsregeln entsprechen rekursive Platzhalter null oder mehr Pfadelementen. match/cities/{city}/{document=**} stimmt mit Dokumenten in allen Untersammlungen sowie mit Dokumenten in der Sammlung cities überein.

Sie müssen die Version 2 aktivieren, indem Sie rules_version = '2'; oben in Ihren Sicherheitsregeln hinzufügen:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // Matches any document in the cities collection as well as any document
    // in a subcollection.
    match /cities/{city}/{document=**} {
      allow read, write: if <condition>;
    }
  }
}

Sie können höchstens einen rekursiven Platzhalter pro Match-Anweisung haben, aber in Version 2 können Sie diesen Platzhalter überall in der Match-Anweisung platzieren. Beispiel:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // Matches any document in the songs collection group
    match /{path=**}/songs/{song} {
      allow read, write: if <condition>;
    }
  }
}

Wenn Sie Abfragen von Sammlungsgruppen verwenden, müssen Sie die Version 2 verwenden, siehe Abfragen von Sammlungsgruppen schützen.

Beschränkungen für Sicherheitsregeln

Beachten Sie bei der Arbeit mit Sicherheitsregeln die folgenden Beschränkungen:

Limit Details
Maximale Anzahl exists()-, get()- und getAfter()-Aufrufe pro Anfrage
  • 10 für Einzeldokumentanfragen und Abfrage-Anfragen.

  • 20 für Lesevorgänge, Transaktionen und Batch-Schreibvorgänge für mehrere Dokumente. Das vorherige Limit von 10 gilt auch für jeden Vorgang.

    Angenommen, Sie erstellen eine Batch-Schreibanfrage mit 3 Schreibvorgängen und Ihre Sicherheitsregeln verwenden 2 Dokumentzugriffsaufrufe, um jeden Schreibvorgang zu validieren. In diesem Fall verwendet jeder Schreibvorgang 2 von seinen 10 Zugriffsaufrufen und die Batch-Schreibanfrage 6 von ihren 20 Zugriffsaufrufen.

Das Überschreiten eines dieser Limits führt zu einem Fehler mit Berechtigungsverweigerung.

Einige Dokumentzugriffsaufrufe können zwischengespeichert werden. Zwischengespeicherte Aufrufe werden nicht in die Limits einberechnet.
Maximale Tiefe verschachtelter match-Anweisungen 10
Maximale Pfadlänge in Pfadsegmenten, die innerhalb eines Satzes von verschachtelten match-Anweisungen zulässig ist 100
Maximale Anzahl Pfaderfassungsvariablen, die in einem Satz verschachtelter match-Anweisungen zulässig ist 20
Maximale Funktionsaufruftiefe 20
Maximale Anzahl Funktionsargumente 7
Maximale Anzahl let-Variablenbindungen pro Funktion 10
Maximale Anzahl rekursiver oder zyklischer Funktionsaufrufe 0 (nicht zulässig)
Maximale Anzahl bewerteter Ausdrücke pro Anfrage 1.000
Maximale Größe eines Regelsatzes Regelsätze müssen zwei Größenbeschränkungen genügen:
  • Ein Limit von 256 KB für die Größe der Textquelle des Regelsatzes, die über die Firebase-Konsole oder die Befehlszeile mit firebase deploy veröffentlicht wird.
  • Ein Limit von 250 KB für die Größe des kompilierten Regelsatzes, der entsteht, wenn Firebase die Quelle verarbeitet und im Backend aktiviert.

Cloud Storage

Grundstruktur

Firebase Security Rules in Cloud Firestore und Cloud Storage verwenden die folgende Struktur und Syntax:

service <<name>> {
  // Match the resource path.
  match <<path>> {
    // Allow the request if the following conditions are true.
    allow <<methods>> : if <<condition>>
  }
}

Die folgenden Schlüsselkonzepte sind wichtig, wenn Sie die Regeln erstellen:

  • Anfrage:Die Methode oder Methoden, die in der allow-Anweisung aufgerufen werden. Dies sind die Methoden, die ausgeführt werden dürfen. Die Standardmethoden sind get, list, create, update und delete. Die Convenience-Methoden read und write ermöglichen einen umfassenden Lese- und Schreibzugriff auf die angegebene Datenbank oder den angegebenen Speicherpfad.
  • Pfad:Der Datenbank- oder Speicherort, dargestellt als URI-Pfad.
  • Regel:Die allow-Anweisung, die eine Bedingung enthält, die eine Anfrage zulässt, wenn sie als „true“ ausgewertet wird.

Übereinstimmende Pfade

Cloud Storage Security Rules match die Dateipfade, die für den Zugriff auf Dateien in Cloud Storage verwendet werden. Regeln können match genaue Pfade oder Platzhalterpfade enthalten und auch verschachtelt werden. Wenn keine Abgleichsregel eine Anfragemethode zulässt oder die Bedingung false ergibt, wird die Anfrage abgelehnt.

Genaue Übereinstimmungen

// Exact match for "images/profilePhoto.png"
match /images/profilePhoto.png {
  allow write: if <condition>;
}

// Exact match for "images/croppedProfilePhoto.png"
match /images/croppedProfilePhoto.png {
  allow write: if <other_condition>;
}

Verschachtelte Übereinstimmungen

// Partial match for files that start with "images"
match /images {
  // Exact match for "images/profilePhoto.png"
  match /profilePhoto.png {
    allow write: if <condition>;
  }

  // Exact match for "images/croppedProfilePhoto.png"
  match /croppedProfilePhoto.png {
    allow write: if <other_condition>;
  }
}

Platzhalterübereinstimmungen

Regeln können auch verwendet werden, um ein Muster mit Platzhaltern zu match. Ein Platzhalter ist eine benannte Variable, die entweder einen einzelnen String wie profilePhoto.png oder mehrere Pfadsegmente wie images/profilePhoto.png darstellt.

Ein Platzhalter wird erstellt, indem Sie geschweifte Klammern um den Platzhalternamen setzen, z. B. {string}. Ein Platzhalter für mehrere Segmente kann deklariert werden, indem dem Platzhalternamen =** hinzugefügt wird, z. B. {path=**}:

// Partial match for files that start with "images"
match /images {
  // Exact match for "images/*"
  // e.g. images/profilePhoto.png is matched
  match /{imageId} {
    // This rule only matches a single path segment (*)
    // imageId is a string that contains the specific segment matched
    allow read: if <condition>;
  }

  // Exact match for "images/**"
  // e.g. images/users/user:12345/profilePhoto.png is matched
  // images/profilePhoto.png is also matched!
  match /{allImages=**} {
    // This rule matches one or more path segments (**)
    // allImages is a path that contains all segments matched
    allow read: if <other_condition>;
  }
}

Wenn mehrere Regeln mit einer Datei übereinstimmen, ist das Ergebnis das OR des Ergebnisses aller Regelauswertungen. Wenn also eine Regel, die auf die Datei zutrifft, als true ausgewertet wird, ist das Ergebnis true.

In den Regeln kann die Datei „images/profilePhoto.png“ gelesen werden, wenn entweder condition oder other_condition als „true“ ausgewertet werden. Die Datei „images/users/user:12345/profilePhoto.png“ unterliegt nur dem Ergebnis von other_condition.

Auf eine Platzhaltervariable kann aus der Autorisierung für match Dateinamen oder Pfade verwiesen werden:

// Another way to restrict the name of a file
match /images/{imageId} {
  allow read: if imageId == "profilePhoto.png";
}

Cloud Storage Security Rules werden nicht kaskadiert und Regeln werden nur ausgewertet, wenn der Anfragepfad mit einem Pfad mit angegebenen Regeln übereinstimmt.

Bewertung anfordern

Hochladen, Herunterladen, Metadatenänderungen und Löschvorgänge werden anhand der request bewertet, die an Cloud Storage gesendet werden. Die Variable request enthält den Pfad, in dem die Anfrage ausgeführt wird, die Zeit, zu der die Anfrage empfangen wird, und den neuen resource-Wert, wenn es sich um eine Schreibanfrage handelt. HTTP-Header und der Authentifizierungsstatus sind ebenfalls enthalten.

Das request-Objekt enthält auch die eindeutige ID des Nutzers und die Firebase Authentication-Nutzlast im request.auth-Objekt, die im Abschnitt Authentifizierung der Dokumentation näher erläutert wird.

Eine vollständige Liste der Attribute im request-Objekt finden Sie unten:

Attribut Typ Beschreibung
auth map<string, string> Wenn ein Nutzer angemeldet ist, werden uid, die eindeutige ID des Nutzers, und token, eine Karte mit Firebase Authentication-JWT-Anforderungen, bereitgestellt. Andernfalls ist es null.
params map<string, string> Map mit den Abfrageparametern der Anfrage.
path Pfad Ein path, das den Pfad darstellt, für den die Anfrage ausgeführt wird.
resource map<string, string> Der neue Ressourcenwert, der nur in write-Anfragen vorhanden ist.
time timestamp Ein Zeitstempel, der die Serverzeit angibt, zu der die Anfrage ausgewertet wird.

Ressourcenbewertung

Bei der Auswertung von Regeln sollten Sie auch die Metadaten der Datei berücksichtigen, die hochgeladen, heruntergeladen, geändert oder gelöscht wird. So können Sie komplexe und leistungsstarke Regeln erstellen, mit denen Sie beispielsweise nur Dateien mit bestimmten Inhaltstypen hochladen oder nur Dateien löschen lassen, die eine bestimmte Größe überschreiten.

Firebase Security Rules für Cloud Storage stellt Dateimetadaten im resource-Objekt bereit, das Schlüssel/Wert-Paare der Metadaten enthält, die in einem Cloud Storage-Objekt angezeigt werden. Diese Eigenschaften können in read- oder write-Anfragen geprüft werden, um die Datenintegrität zu gewährleisten.

Bei write-Anfragen (z. B. Uploads, Metadatenaktualisierungen und Löschvorgänge) haben Sie zusätzlich zum resource-Objekt, das Dateimetadaten für die Datei enthält, die sich im Anfragepfad befindet, auch die Möglichkeit, das request.resource-Objekt zu verwenden. Dieses enthält eine Teilmenge der Dateimetadaten, die geschrieben werden sollen, wenn der Schreibvorgang zulässig ist. Mit diesen beiden Werten können Sie die Datenintegrität sicherstellen oder Anwendungsbeschränkungen wie Dateityp oder ‑größe erzwingen.

Eine vollständige Liste der Attribute im resource-Objekt ist verfügbar:

Attribut Typ Beschreibung
name String Der vollständige Name des Objekts
bucket String Der Name des Buckets, in dem sich dieses Objekt befindet.
generation int Die Google Cloud Storage-Objektgenerierung dieses Objekts.
metageneration int Die Google Cloud Storage-Objektmetagenerierung dieses Objekts.
size int Größe des Objekts in Byte.
timeCreated timestamp Ein Zeitstempel, der angibt, wann ein Objekt erstellt wurde.
updated timestamp Ein Zeitstempel, der angibt, wann ein Objekt zuletzt aktualisiert wurde.
md5Hash String Ein MD5-Hash des Objekts.
crc32c String Ein CRC32C-Hash des Objekts.
etag String Das ETag, das diesem Objekt zugeordnet ist.
contentDisposition String Die Inhaltsdisposition, die diesem Objekt zugeordnet ist.
contentEncoding String Die mit diesem Objekt verknüpfte Inhaltscodierung.
contentLanguage String Die mit diesem Objekt verknüpfte Sprache des Inhalts.
contentType String Der Inhaltstyp, der diesem Objekt zugeordnet ist.
metadata map<string, string> Schlüssel/Wert-Paare für zusätzliche, vom Entwickler angegebene benutzerdefinierte Metadaten.

request.resource enthält alle diese Elemente mit Ausnahme von generation, metageneration, etag, timeCreated und updated.

Beschränkungen für Sicherheitsregeln

Beachten Sie bei der Arbeit mit Sicherheitsregeln die folgenden Beschränkungen:

Limit Details
Maximale Anzahl von firestore.exists()- und firestore.get()-Aufrufen pro Anfrage

2 für Einzeldokumentanfragen und Abfrage-Anfragen.

Das Überschreiten dieses Limits führt zu einem Fehler mit Berechtigungsverweigerung.

Zugriffsaufrufe für dieselben Dokumente können zwischengespeichert werden. Zwischengespeicherte Aufrufe werden nicht auf die Limits angerechnet.

Vollständiges Beispiel

Wenn Sie alles zusammenfügen, können Sie ein vollständiges Beispiel für Regeln für eine Bildspeicherlösung erstellen:

service firebase.storage {
 match /b/{bucket}/o {
   match /images {
     // Allow write files to the path "images/*", subject to the constraints:
     // 1) File is less than 5MB
     // 2) Content type is an image
     // 3) Uploaded content type matches existing content type
     // 4) Filename (stored in imageId wildcard variable) is less than 32 characters
     match /{imageId} {
       allow read;
       allow write: if request.resource.size < 5 * 1024 * 1024
                    && request.resource.contentType.matches('image/.*')
                    && request.resource.contentType == resource.contentType
                    && imageId.size() < 32
     }
   }
 }
}

Realtime Database

Grundstruktur

In Realtime Database bestehen Firebase Security Rules aus JavaScript-ähnlichen Ausdrücken in einem JSON-Dokument.

Sie verwenden die folgende Syntax:

{
  "rules": {
    "<<path>>": {
    // Allow the request if the condition for each method is true.
      ".read": <<condition>>,
      ".write": <<condition>>,
      ".validate": <<condition>>
    }
  }
}

Eine Regel besteht aus drei grundlegenden Elementen:

  • Pfad:Der Speicherort der Datenbank. Dies entspricht der JSON-Struktur Ihrer Datenbank.
  • Anfrage:Dies sind die Methoden, mit denen die Regel Zugriff gewährt. Die Regeln read und write gewähren umfassenden Lese- und Schreibzugriff, während die Regeln validate als sekundäre Bestätigung dienen, um den Zugriff basierend auf eingehenden oder vorhandenen Daten zu gewähren.
  • Bedingung:Die Bedingung, die eine Anfrage zulässt, wenn sie als „true“ ausgewertet wird.

So werden Regeln auf Pfade angewendet

In Realtime Database werden Rules atomar angewendet. Das bedeutet, dass Regeln auf übergeordneten Knoten Regeln auf untergeordneten Knoten überschreiben und Regeln auf einem untergeordneten Knoten keinen Zugriff auf einen übergeordneten Pfad gewähren können. Sie können den Zugriff nicht auf einer tieferen Ebene in Ihrer Datenbankstruktur einschränken oder widerrufen, wenn Sie ihn bereits für einen der übergeordneten Pfade gewährt haben.

Beachten Sie die folgenden Regeln:

{
  "rules": {
     "foo": {
        // allows read to /foo/*
        ".read": "data.child('baz').val() === true",
        "bar": {
          // ignored, since read was allowed already
          ".read": false
        }
     }
  }
}

Diese Sicherheitsstruktur ermöglicht das Lesen von /bar/, wenn /foo/ ein untergeordnetes Element baz mit dem Wert true enthält. Die Regel ".read": false unter /foo/bar/ hat hier keine Auswirkungen, da der Zugriff nicht über einen untergeordneten Pfad widerrufen werden kann.

Das ist zwar nicht sofort intuitiv, aber ein wichtiger Bestandteil der Regelsprache. So lassen sich sehr komplexe Zugriffsberechtigungen mit minimalem Aufwand implementieren. Das ist besonders für die nutzerbasierte Sicherheit nützlich.

.validate-Regeln werden jedoch nicht kaskadiert. Alle „validate“-Regeln müssen auf allen Ebenen der Hierarchie erfüllt sein, damit ein Schreibvorgang zulässig ist.

Da Regeln außerdem nicht auf einen übergeordneten Pfad angewendet werden, schlagen Lese- oder Schreibvorgänge fehl, wenn am angeforderten Ort oder an einem übergeordneten Ort keine Regel vorhanden ist, die Zugriff gewährt. Selbst wenn jeder betroffene untergeordnete Pfad zugänglich ist, schlägt das Lesen am übergeordneten Speicherort vollständig fehl. Stellen Sie sich folgende Struktur vor:

{
  "rules": {
    "records": {
      "rec1": {
        ".read": true
      },
      "rec2": {
        ".read": false
      }
    }
  }
}

Wenn man nicht weiß, dass Regeln atomar ausgewertet werden, könnte es so aussehen, als würde das Abrufen des Pfads /records/ rec1, aber nicht rec2 zurückgeben. Das tatsächliche Ergebnis ist jedoch ein Fehler:

JavaScript
var db = firebase.database();
db.ref("records").once("value", function(snap) {
  // success method is not called
}, function(err) {
  // error callback triggered with PERMISSION_DENIED
});
Objective-C
Hinweis:Dieses Firebase-Produkt ist nicht für das App Clip-Ziel verfügbar. 
FIRDatabaseReference *ref = [[FIRDatabase database] reference];
[[_ref child:@"records"] observeSingleEventOfType:FIRDataEventTypeValue withBlock:^(FIRDataSnapshot *snapshot) {
  // success block is not called
} withCancelBlock:^(NSError * _Nonnull error) {
  // cancel block triggered with PERMISSION_DENIED
}];
Swift
Hinweis:Dieses Firebase-Produkt ist nicht für das App Clip-Ziel verfügbar. 
var ref = FIRDatabase.database().reference()
ref.child("records").observeSingleEventOfType(.Value, withBlock: { snapshot in
    // success block is not called
}, withCancelBlock: { error in
    // cancel block triggered with PERMISSION_DENIED
})
Java
FirebaseDatabase database = FirebaseDatabase.getInstance();
DatabaseReference ref = database.getReference("records");
ref.addListenerForSingleValueEvent(new ValueEventListener() {
  @Override
  public void onDataChange(DataSnapshot snapshot) {
    // success method is not called
  }

  @Override
  public void onCancelled(FirebaseError firebaseError) {
    // error callback triggered with PERMISSION_DENIED
  });
});
REST
curl https://docs-examples.firebaseio.com/rest/records/
# response returns a PERMISSION_DENIED error

Da der Lesevorgang unter /records/ atomar ist und es keine Leseregel gibt, die Zugriff auf alle Daten unter /records/ gewährt, wird ein PERMISSION_DENIED-Fehler ausgegeben. Wenn wir diese Regel im Sicherheitssimulator in unserer Firebase-Konsole auswerten, sehen wir, dass der Lesevorgang abgelehnt wurde:

Attempt to read /records with auth=Success(null)
    /
    /records

No .read rule allowed the operation.
Read was denied.

Der Vorgang wurde abgelehnt, weil keine Leseregel den Zugriff auf den Pfad /records/ zuließ. Die Regel für rec1 wurde jedoch nie ausgewertet, da sie nicht im angeforderten Pfad enthalten war. Um rec1 abzurufen, müssten wir direkt darauf zugreifen:

JavaScript
var db = firebase.database();
db.ref("records/rec1").once("value", function(snap) {
  // SUCCESS!
}, function(err) {
  // error callback is not called
});
Objective-C
Hinweis:Dieses Firebase-Produkt ist nicht für das App Clip-Ziel verfügbar. 
FIRDatabaseReference *ref = [[FIRDatabase database] reference];
[[ref child:@"records/rec1"] observeSingleEventOfType:FEventTypeValue withBlock:^(FIRDataSnapshot *snapshot) {
    // SUCCESS!
}];
Swift
Hinweis:Dieses Firebase-Produkt ist nicht für das App Clip-Ziel verfügbar. 
var ref = FIRDatabase.database().reference()
ref.child("records/rec1").observeSingleEventOfType(.Value, withBlock: { snapshot in
    // SUCCESS!
})
Java
FirebaseDatabase database = FirebaseDatabase.getInstance();
DatabaseReference ref = database.getReference("records/rec1");
ref.addListenerForSingleValueEvent(new ValueEventListener() {
  @Override
  public void onDataChange(DataSnapshot snapshot) {
    // SUCCESS!
  }

  @Override
  public void onCancelled(FirebaseError firebaseError) {
    // error callback is not called
  }
});
REST
curl https://docs-examples.firebaseio.com/rest/records/rec1
# SUCCESS!

Standortvariable

Realtime Database Rules unterstützen eine $location-Variable, um Pfadsegmente abzugleichen. Verwenden Sie das Präfix $ vor dem Pfadsegment, damit die Regel auf alle untergeordneten Knoten entlang des Pfads angewendet wird.

  {
    "rules": {
      "rooms": {
        // This rule applies to any child of /rooms/, the key for each room id
        // is stored inside $room_id variable for reference
        "$room_id": {
          "topic": {
            // The room's topic can be changed if the room id has "public" in it
            ".write": "$room_id.contains('public')"
          }
        }
      }
    }
  }

Sie können $variable auch parallel zu konstanten Pfadnamen verwenden.

  {
    "rules": {
      "widget": {
        // a widget can have a title or color attribute
        "title": { ".validate": true },
        "color": { ".validate": true },

        // but no other child paths are allowed
        // in this case, $other means any key excluding "title" and "color"
        "$other": { ".validate": false }
      }
    }
  }