Funktionsweise von Sicherheitsregeln

Cloud Firestore

Grundstruktur

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

Beim Erstellen der Regeln ist es wichtig, die folgenden Schlüsselkonzepte zu verstehen:

• Anfrage: Die Methode oder Methoden, die in der allow Anweisung aufgerufen werden. Dies sind Methoden, deren Ausführung Sie zulassen. Die Standardmethoden sind: get , list , create , update und delete . Die komfortablen read und write ermöglichen einen 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. Version 2 der Regeln ändert das Verhalten rekursiver Platzhalter {name=**} . Sie müssen Version 2 verwenden, wenn Sie Sammlungsgruppenabfragen verwenden möchten. Sie müssen sich für Version 2 anmelden, indem Sie rules_version = '2'; festlegen. die erste Zeile Ihrer Sicherheitsregeln:

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

Passende Wege

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

Im obigen Beispiel verwendet die match-Anweisung die Platzhaltersyntax {city} . Dies bedeutet, dass die Regel für jedes Dokument in der cities gilt, z. B. /cities/SF oder /cities/NYC . Wenn die allow in der Match-Anweisung ausgewertet werden, wird die city in den Namen des Stadtdokuments aufgelöst, z. B. SF oder NYC .

Passende Untersammlungen

Daten in Cloud Firestore sind in Dokumentensammlungen organisiert, und jedes Dokument kann die Hierarchie durch Untersammlungen erweitern. Es ist wichtig zu verstehen, wie Sicherheitsregeln mit hierarchischen Daten interagieren.

Stellen Sie sich die Situation vor, in der jedes Dokument in der cities eine Untersammlung landmarks enthält. Sicherheitsregeln gelten nur für den übereinstimmenden Pfad, daher gelten die für die cities definierten Zugriffskontrollen nicht für die Untersammlung landmarks . Schreiben Sie stattdessen explizite Regeln, um den Zugriff auf Untersammlungen zu steuern:

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 match Anweisungen ist der Pfad der inneren match Anweisung immer relativ zum Pfad der äußeren match Anweisung. Die folgenden Regelsätze sind daher gleichwertig:

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 Sie möchten, dass Regeln auf eine beliebig tiefe Hierarchie angewendet werden, 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 passende Pfadsegment, auch wenn sich das Dokument in einer tief verschachtelten Untersammlung befindet. Beispielsweise würden die oben aufgeführten Regeln mit einem Dokument übereinstimmen, das sich unter /cities/SF/landmarks/coit_tower befindet, und der Wert der document 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 Sammlungsgruppenabfragen verwenden, müssen Sie Version 2 verwenden, siehe Sichern von Sammlungsgruppenabfragen .

Überlappende Match-Anweisungen

Es ist möglich, dass ein Dokument mit mehr als einer match Anweisung übereinstimmt. Falls mehrere allow mit einer Anfrage übereinstimmen, wird der Zugriff zugelassen, wenn eine 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 obigen Beispiel sind alle Lese- und Schreibvorgänge in der Sammlung „ cities “ zulässig, da die zweite Regel immer true ist, obwohl die erste Regel immer „ false ist.

Grenzwerte der Sicherheitsregeln

Beachten Sie beim Arbeiten mit Sicherheitsregeln die folgenden Einschränkungen:

Cloud-Speicher

Grundstruktur

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

Beim Erstellen der Regeln ist es wichtig, die folgenden Schlüsselkonzepte zu verstehen:

• Anfrage: Die Methode oder Methoden, die in der allow Anweisung aufgerufen werden. Dies sind Methoden, deren Ausführung Sie zulassen. Die Standardmethoden sind: get , list , create , update und delete . Die komfortablen read und write ermöglichen einen 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.

Passende Wege

Cloud Storage-Sicherheitsregeln stimmen mit den Dateipfaden match , die für den Zugriff auf Dateien im Cloud Storage verwendet werden. Regeln können exakten Pfaden oder Platzhalterpfaden match und Regeln können auch verschachtelt sein. Wenn keine Übereinstimmungsregel eine Anforderungsmethode zulässt oder die Bedingung false ergibt, wird die Anforderung 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>;
  }
}

Wildcard-Matches

Regeln können auch verwendet werden, um ein Muster mithilfe von Platzhaltern match . Ein Platzhalter ist eine benannte Variable, die entweder eine einzelne Zeichenfolge wie profilePhoto.png oder mehrere Pfadsegmente wie images/profilePhoto.png darstellt.

Ein Platzhalter wird erstellt, indem geschweifte Klammern um den Namen des Platzhalters eingefügt werden, z. B. {string} . Ein Platzhalter für mehrere Segmente kann durch Hinzufügen =** zum Platzhalternamen deklariert werden, 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. Das heißt, wenn eine Regel, mit der die Datei übereinstimmt, true ergibt, ist das Ergebnis true .

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

Auf eine Platzhaltervariable kann innerhalb des match verwiesen werden, indem der Dateiname oder der Pfad autorisiert wird:

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

Cloud Storage-Sicherheitsregeln werden nicht kaskadiert und Regeln werden nur ausgewertet, wenn der Anforderungspfad mit einem Pfad mit angegebenen Regeln übereinstimmt.

Bewertung anfordern

Uploads, Downloads, Metadatenänderungen und Löschungen werden anhand der an Cloud Storage gesendeten request ausgewertet. Die request enthält den Dateipfad, in dem die Anforderung ausgeführt wird, die Zeit, zu der die Anforderung empfangen wurde, und den neuen resource , wenn es sich bei der Anforderung um eine Schreibanforderung handelt. HTTP-Header und Authentifizierungsstatus sind ebenfalls enthalten.

Das request enthält außerdem die eindeutige ID des Benutzers und die Firebase-Authentifizierungsnutzlast im Objekt „ request.auth , was im Abschnitt „Authentifizierung“ der Dokumentation näher erläutert wird.

Eine vollständige Liste der Eigenschaften im request finden Sie unten:

Ressourcenbewertung

Beim Auswerten von Regeln möchten Sie möglicherweise auch die Metadaten der Datei auswerten, die hochgeladen, heruntergeladen, geändert oder gelöscht wird. Auf diese Weise können Sie komplexe und leistungsstarke Regeln erstellen, die beispielsweise nur das Hochladen von Dateien mit bestimmten Inhaltstypen zulassen oder nur das Löschen von Dateien ab einer bestimmten Größe zulassen.

Firebase-Sicherheitsregeln für Cloud Storage stellen Dateimetadaten im resource 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 überprüft werden, um die Datenintegrität sicherzustellen.

Bei write (z. B. Uploads, Metadatenaktualisierungen und Löschvorgängen) haben Sie zusätzlich zum resource , das Dateimetadaten für die Datei enthält, die derzeit im Anforderungspfad vorhanden ist, auch die Möglichkeit, das Objekt request.resource zu verwenden. die eine Teilmenge der Dateimetadaten enthält, die geschrieben werden sollen, wenn das Schreiben zulässig ist. Sie können diese beiden Werte verwenden, um die Datenintegrität sicherzustellen oder Anwendungsbeschränkungen wie Dateityp oder -größe durchzusetzen.

Eine vollständige Liste der Eigenschaften im resource finden Sie unten:

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

Grenzen der Sicherheitsregeln

Beachten Sie beim Arbeiten mit Sicherheitsregeln die folgenden Einschränkungen:

Vollständiges Beispiel

Alles in allem 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 {
     // 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
     }
   }
 }
}

Echtzeitdatenbank

Grundstruktur

In der Echtzeitdatenbank bestehen Firebase-Sicherheitsregeln aus JavaScript-ähnlichen Ausdrücken, die in einem JSON-Dokument enthalten sind.

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 Grundelementen:

• Pfad: Der Datenbankspeicherort. Dies spiegelt die JSON-Struktur Ihrer Datenbank wider.
• Anfrage: Dies sind die Methoden, die die Regel verwendet, um Zugriff zu gewähren. Die read und write gewähren umfassenden Lese- und Schreibzugriff, während validate als sekundäre Überprüfung fungieren, um den Zugriff auf der Grundlage eingehender oder vorhandener Daten zu gewähren.
• Bedingung: Die Bedingung, die eine Anfrage zulässt, wenn sie als wahr ausgewertet wird.

Wie Regeln auf Pfade angewendet werden

In der Echtzeitdatenbank gelten Regeln atomar, was bedeutet, dass Regeln auf übergeordneten Knoten höherer Ebene die Regeln auf detaillierteren untergeordneten Knoten außer Kraft setzen 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 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/ immer dann, wenn /foo/ ein untergeordnetes baz mit dem Wert true enthält. Die Regel ".read": false unter /foo/bar/ hat hier keine Auswirkung, da der Zugriff nicht durch einen untergeordneten Pfad widerrufen werden kann.

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

Allerdings sind .validate Regeln nicht kaskadierbar. Damit ein Schreibvorgang zulässig ist, müssen alle Validierungsregeln auf allen Ebenen der Hierarchie erfüllt sein.

Da Regeln außerdem nicht auf einen übergeordneten Pfad zurückgreifen, schlagen Lese- oder Schreibvorgänge fehl, wenn am angeforderten Speicherort oder an einem übergeordneten Speicherort keine Regel vorhanden ist, die Zugriff gewährt. Selbst wenn auf alle betroffenen untergeordneten Pfade 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
      }
    }
  }
}

Ohne zu verstehen, 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:

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, können wir sehen, dass der Lesevorgang verweigert 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. Beachten Sie jedoch, dass die Regel für rec1 nie ausgewertet wurde, da sie sich nicht im von uns 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

Echtzeitdatenbankregeln unterstützen eine $location Variable zum Abgleichen von Pfadsegmenten. Verwenden Sie das Präfix $ vor Ihrem Pfadsegment, um Ihre Regel an alle untergeordneten Knoten entlang des Pfads anzupassen.

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