Funktionsweise von Sicherheitsregeln

Cloud Firestore

Grundstruktur

Firebase Security Rules in Cloud Firestore und Cloud Storage hat 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 wichtigen Konzepte sollten Sie beim Erstellen der Regeln kennen:

• Anfrage: Die Methode oder Methoden, die in der allow-Anweisung aufgerufen werden. Das sind Methoden, die Sie zulassen. Die Standardmethoden sind: get, list, create, update und delete. Die praktischen Methoden read und write ermöglichen umfassenden Lese- und Schreibzugriff auf die angegebene Datenbank oder den angegebenen Speicherpfad.
• Pfad:Die Datenbank oder der Speicherort, dargestellt als URI-Pfad.
• Regel:Die allow-Anweisung, die eine Bedingung enthält, die eine Anfrage zulässt, wenn sie als wahr 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 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

Daten in Cloud Firestore sind in Dokumentensammlungen organisiert. Jedes Dokument kann die 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>;
    }
  }
}

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.

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 hat 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 wichtigen Konzepte sollten Sie beim Erstellen der Regeln kennen:

• Anfrage: Die Methode oder Methoden, die in der allow-Anweisung aufgerufen werden. Das sind Methoden, die Sie zulassen. Die Standardmethoden sind: get, list, create, update und delete. Die praktischen Methoden read und write ermöglichen umfassenden Lese- und Schreibzugriff auf die angegebene Datenbank oder den angegebenen Speicherpfad.
• Pfad:Die Datenbank oder der Speicherort, dargestellt als URI-Pfad.
• Regel:Die allow-Anweisung, die eine Bedingung enthält, die eine Anfrage zulässt, 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 match genaue Pfade oder Platzhalterpfade sein und auch verschachtelt werden. 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

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

Platzhalter werden durch geschweifte Klammern um den Platzhalternamen herum erstellt, z. B. {string}. Ein Platzhalter mit mehreren Segmenten 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, mit der die Datei übereinstimmt, den Wert true hat, ist das Ergebnis true.

In den obigen Regeln kann die Datei „images/profilePhoto.png“ gelesen werden, wenn entweder condition oder other_condition zu „wahr“ ausgewertet wird. Für die Datei „images/users/user:12345/profilePhoto.png“ gilt dagegen nur das Ergebnis von other_condition.

Eine Platzhaltervariable kann innerhalb der match-Anweisung für die Dateinamen- oder Pfadautorisierung referenziert 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 beantragen

Uploads, Downloads, Metadatenänderungen und Löschungen werden anhand der request bewertet, die an Cloud Storage gesendet wird. Die Variable request enthält den Dateipfad, unter dem die Anfrage ausgeführt wird, die Uhrzeit, zu der die Anfrage empfangen wird, und den neuen Wert für resource, wenn es sich um eine Schreibanfrage handelt. HTTP-Header und Authentifizierungsstatus sind ebenfalls enthalten.

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 hochgeladenen, heruntergeladenen, geänderten oder gelöschten Dateien berücksichtigen. So können Sie komplexe und leistungsstarke Regeln erstellen, mit denen beispielsweise nur Dateien mit bestimmten Inhaltstypen hochgeladen oder nur Dateien mit einer bestimmten Größe gelöscht werden dürfen.

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 bei 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) können Sie zusätzlich zum resource-Objekt, das Dateimetadaten für die Datei enthält, die sich derzeit am Anfragepfad befindet, auch das request.resource-Objekt verwenden. Dieses enthält einen Teil der Dateimetadaten, die geschrieben werden sollen, sofern das Schreiben zulässig ist. Mit diesen beiden Werten können Sie die Datenintegrität gewährleisten oder Anwendungseinschränkungen wie Dateityp oder -größe erzwingen.

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

request.resource enthält alle diese 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:

Vollständiges Beispiel

Zusammengenommen können Sie ein vollständiges Beispiel für Regeln für eine Lösung zum Speichern von Bildern erstellen:

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

Die 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 den 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: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 der höheren Ebene Regeln auf untergeordneten Knoten mit detaillierteren Zugriffsrechten überschreiben und Regeln auf einem tieferen Knoten keinen Zugriff auf einen übergeordneten Pfad gewähren können. Sie können den Zugriff auf einen tieferen Pfad in Ihrer Datenbankstruktur nicht verfeinern oder widerrufen, wenn Sie ihn bereits für einen der übergeordneten Pfade gewährt haben.

Beachten Sie dabei die folgenden Regeln:

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

Mit dieser Sicherheitsstruktur kann /bar/ gelesen werden, 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.

Dieser Teil der Regelsprache ist zwar nicht sofort intuitiv, aber sehr leistungsfähig und ermöglicht die Implementierung sehr komplexer Zugriffsberechtigungen mit minimalem Aufwand. Das ist besonders für die nutzerbasierte Sicherheit nützlich.

.validate-Regeln werden jedoch nicht kaskadiert. Damit ein Schreibvorgang zulässig ist, müssen alle Validierungsregeln auf allen Ebenen der Hierarchie erfüllt sein.

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. Selbst wenn auf jeden betroffenen untergeordneten Pfad zugegriffen werden kann, schlägt das Lesen am übergeordneten Speicherort vollständig fehl. Betrachten Sie diese Struktur:

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

Wenn Sie nicht wissen, dass Regeln atomar ausgewertet werden, könnte es so aussehen, als würde beim Abrufen des Pfads /records/ 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 bei /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, da keine Leseregel den Zugriff auf den Pfad /records/ erlaubte. Die Regel für rec1 wurde jedoch nie ausgewertet, da sie sich nicht im angeforderten Pfad befand. 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ützt eine $location-Variable zum Abgleichen von Pfadsegmenten. Verwenden Sie das Präfix $ vor dem Pfadsegment, um Ihre Regel mit allen untergeordneten Knoten entlang des Pfads abzugleichen.

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