Funktionsweise von Sicherheitsregeln

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.

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

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:

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:

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:

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:

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:

var db = firebase.database();
db.ref("records").once("value", function(snap) {
  // success method is not called
}, function(err) {
  // error callback triggered with PERMISSION_DENIED
});

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

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

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

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:

var db = firebase.database();
db.ref("records/rec1").once("value", function(snap) {
  // SUCCESS!
}, function(err) {
  // error callback is not called
});

FIRDatabaseReference *ref = [[FIRDatabase database] reference];
[[ref child:@"records/rec1"] observeSingleEventOfType:FEventTypeValue withBlock:^(FIRDataSnapshot *snapshot) {
    // SUCCESS!
}];

var ref = FIRDatabase.database().reference()
ref.child("records/rec1").observeSingleEventOfType(.Value, withBlock: { snapshot in
    // SUCCESS!
})

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

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