Funktionsweise von Sicherheitsregeln

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

Firebase Security Rules entfernt die mittlere Ebene (Serverebene) und ermöglicht Ihnen, pfadbasierte Berechtigungen für Clients, die eine direkte Verbindung zu Ihren Daten herstellen. In diesem Leitfaden erfahren Sie, Weitere Informationen dazu, wie Regeln auf eingehende Anfragen angewendet werden.

Wählen Sie ein Produkt aus, um mehr über die zugehörigen 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>>
  }
}

Sie sollten beim Erstellen der Regeln die folgenden Schlüsselkonzepte kennen:

  • Anfrage: Die Methode oder Methoden, die in der allow-Anweisung aufgerufen werden. Dies sind die Sie ausführen dürfen. Die Standardmethoden sind get, list, create, update und delete. Die Convenience-Methoden read und write umfassenden Lese- und Schreibzugriff auf die angegebene Datenbank oder den Speicherpfad ermöglichen
  • Pfad: Die Datenbank oder der Speicherort, dargestellt als URI-Pfad.
  • Regel:Die allow-Anweisung, die eine Bedingung enthält, die ein -Anforderung, wenn sie als wahr ausgewertet wird.

Sicherheitsregeln Version 2

Ab Mai 2019 ist Version 2 der Firebase-Sicherheitsregeln jetzt 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 Sie müssen die Version 2, indem Sie rules_version = '2'; als erste Zeile in Ihrer Sicherheit festlegen Regeln:

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 oben 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 .

Übereinstimmende Untersammlungen

Die Daten in Cloud Firestore sind in Dokumentensammlungen organisiert, die jeweils kann die Hierarchie durch untergeordnete Sammlungen 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>;
    }
  }
}

Rekursive Platzhalter

Wenn Regeln auf eine beliebig tiefe Hierarchie angewendet werden sollen, verwenden Sie die Methode 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.

Ü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 or subcollections.
    match /cities/{document=**} {
      allow read, write: if true;
    }
  }
}

Im oberen 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.

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:
  • Beschränkung der Größe der Textquelle des Regelsatzes auf 256 KB über die Firebase-Konsole oder über die Befehlszeile mit firebase deploy.
  • 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>>
  }
}

Sie sollten beim Erstellen der Regeln die folgenden Schlüsselkonzepte kennen:

  • Anfrage: Die Methode oder Methoden, die in der allow-Anweisung aufgerufen werden. Dies sind die Sie ausführen dürfen. Die Standardmethoden sind get, list, create, update und delete. Die Convenience-Methoden read und write umfassenden Lese- und Schreibzugriff auf die angegebene Datenbank oder den Speicherpfad ermöglichen
  • Pfad: Die Datenbank oder der Speicherort, dargestellt als URI-Pfad.
  • Regel:Die allow-Anweisung, die eine Bedingung enthält, die ein -Anforderung, wenn sie als wahr 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 exakte Pfade oder Platzhalterpfade match und Regeln können auch verschachtelt sein. Wenn keine Übereinstimmungsregel 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>;
  }
}

Platzhalterabgleich

Regeln können auch verwendet werden, um ein Muster mithilfe von Platzhaltern mit „match“ zu versehen. Ein Platzhalter ist ein benannte Variable, die entweder einen einzelnen String wie profilePhoto.png oder mehrere Pfadsegmente, z. B. images/profilePhoto.png.

Ein Platzhalter wird erstellt, indem er in geschweifte Klammern gesetzt wird, z. B.: {string} Ein Platzhalter für mehrere Segmente kann angegeben werden, indem =** zum Platzhaltername wie {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 die OR der Ergebnisse aller für die Auswertung von Regeln. Das heißt, wenn eine Regel, mit der die Datei übereinstimmt, true ergibt, Ergebnis ist true.

In den obigen Regeln wird die Datei „images/profilePhoto.png“ gelesen werden können, wenn condition oder other_condition werden als „true“ ausgewertet, "images/users/user:12345/profilePhoto.png" unterliegt nur dem Ergebnis einer other_condition.

In der match-Bereitstellungsdatei kann auf eine Platzhaltervariable verwiesen werden. Namens- oder Pfadautorisierung:

// 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 die Anfragepfad stimmt mit einem Pfad mit angegebenen Regeln überein.

Bewertung beantragen

Uploads, Downloads, Metadatenänderungen und Löschvorgänge werden mithilfe der request an Cloud Storage gesendet. Die Variable request enthält den Parameter Dateipfad, unter dem die Anfrage ausgeführt wird, also den Zeitpunkt, an dem die Anfrage ausgeführt wird und den neuen resource-Wert, wenn die Anfrage ein Schreibvorgang ist. HTTP-Header Authentifizierungsstatus und Authentifizierungsstatus angegeben.

Das request-Objekt enthält außerdem die eindeutige ID des Nutzers und die Firebase Authentication-Nutzlast im request.auth-Objekt. Weitere Informationen dazu findest du im Abschnitt Authentifizierung der Dokumentation.

Unten finden Sie eine vollständige Liste der Attribute im request-Objekt:

Attribut Typ Beschreibung
auth Map<string, string> Wenn ein Nutzer angemeldet ist, gibt er uid, die eindeutige ID des Nutzers und token, eine Zuordnung von Firebase Authentication JWT-Anforderungen. Andernfalls wird es null
params map<string, string> Zuordnung mit den Abfrageparametern der Anfrage.
path Pfad Ein path, der den Pfad darstellt, in dem sich die Anfrage befindet gearbeitet hat.
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 können Sie auch die Metadaten der Datei auswerten. hochgeladen, heruntergeladen, geändert oder gelöscht werden. So können Sie die beispielsweise nur Dateien mit bestimmten auszuwählen, die hochgeladen werden sollen, oder nur Dateien, die eine bestimmte Größe überschreiten, gelöscht.

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

Bei write-Anfragen (z. B. Uploads, Metadatenaktualisierungen und Löschungen) in Zusätzlich zum resource-Objekt, das die Metadaten der Datei enthält derzeit im Anfragepfad vorhanden ist, können Sie auch den request.resource-Objekt, das eine Teilmenge der Dateimetadaten enthält, die verwendet werden sollen. geschrieben wird, wenn der Schreibvorgang erlaubt ist. Mit diesen beiden Werten können Sie die Datenintegrität gewährleisten oder Anwendungseinschränkungen wie Dateityp oder -größe erzwingen.

Eine vollständige Liste der Eigenschaften im Objekt resource findest du unten:

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

request.resource enthält alle diese außer generation. metageneration, etag, timeCreated und updated.

Limits 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 werden möglicherweise im Cache gespeichert, während Aufrufe im Cache gespeichert werden werden nicht auf die Limits angerechnet.

Vollständiges Beispiel

Durch diese Zusammenfassung können Sie ein vollständiges Beispiel mit Regeln für ein Bild erstellen. Speicherlösung:

service firebase.storage {
 match /b/{bucket}/o {
   match /images {
     // Cascade read to any image type at any path
     match /{allImages=**} {
       allow read;
     }

     // 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) File name (stored in imageId wildcard variable) is less than 32 characters
     match /{imageId} {
       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 besteht Firebase Security Rules aus JavaScript-ähnlichen Ausdrücken, die 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>>
    }
  }
}

Die Regel besteht aus drei grundlegenden Elementen:

  • Pfad: Der Speicherort der Datenbank. Dies spiegelt die JSON-Struktur Ihrer Datenbank wider.
  • Anfrage:Dies sind die Methoden, mit denen die Regel Zugriff gewährt. Die read- und write-Regeln gewähren umfassenden Lese- und Schreibzugriff, während validate-Regeln 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 wahr ausgewertet wird.

Anwendung von Regeln auf Pfade

In Realtime Database werden Rules atomar angewendet. Das bedeutet, dass Regeln auf übergeordneten Knoten höherer Ebene Regeln auf detaillierteren untergeordneten Knoten überschreiben und Regeln auf einem tieferen Knoten keinen Zugriff auf einen übergeordneten Pfad gewähren können. Ich den Zugriff auf einen tieferen Pfad in Ihrer Datenbankstruktur nicht verfeinern oder aufheben können, 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
        }
     }
  }
}

Durch diese Sicherheitsstruktur kann /bar/ jederzeit gelesen werden, wenn /foo/ enthält eine untergeordnete baz mit dem Wert true. Die Regel ".read": false unter /foo/bar/ hat hier keine Auswirkungen, da der Zugriff nicht über einen untergeordneten Pfad widerrufen werden kann.

Auch wenn es nicht sofort intuitiv erscheint, ist dies ein wichtiger Teil des und ermöglicht die Implementierung sehr komplexer Zugriffsrechte. mit minimalem Aufwand. Dies ist besonders nützlich für die nutzerbasierte Sicherheit.

.validate-Regeln werden jedoch nicht kaskadiert. Alle Validierungsregeln muss auf allen Hierarchieebenen erfüllt sein, damit ein Schreibvorgang zulässig ist.

Da Regeln nicht auf übergeordnete Pfade angewendet werden, schlagen Lese- oder Schreibvorgänge fehl, wenn sich am angeforderten Speicherort oder an einem übergeordneten Speicherort keine Regel befindet, die den Zugriff gewährt. Auch wenn alle betroffenen Kinderpfade zugänglich sind, wird das Lesen am übergeordneten Speicherort fehlschlagen. Betrachten Sie diese Struktur:

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

Wenn man nicht versteht, dass Regeln atomar bewertet werden, Beispiel: Beim Abrufen des Pfads /records/ wird rec1 zurückgegeben. aber nicht rec2. 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 im 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 für das App-Clip-Ziel nicht 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 der Fehler PERMISSION_DENIED ausgelöst. Wenn wir diese Regel im Sicherheitssimulator der 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, da keine Leseregel Zugriff auf den Pfad /records/ gewährt hat. 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 im 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 für das App-Clip-Ziel nicht 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 ein $location , um Pfadsegmenten abzugleichen. Verwenden Sie das Präfix $ vor dem Pfad. , um Ihre Regel allen untergeordneten Knoten entlang des Pfads zuzuordnen.

  {
    "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 }
      }
    }
  }