欢迎参加我们将于 2022 年 10 月 18 日举办的 Firebase 峰会(线上线下同时进行),了解 Firebase 如何帮助您加快应用开发速度、满怀信心地发布应用并在之后需要时轻松地扩大应用规模。立即报名

Structurer les règles de sécurité Cloud Firestore

Les règles de sécurité Cloud Firestore vous permettent de contrôler l'accès aux documents et aux collections de votre base de données. La syntaxe des règles flexibles vous permet de créer des règles qui correspondent à tout, de toutes les écritures sur l'ensemble de la base de données aux opérations sur un document spécifique.

Ce guide décrit la syntaxe et la structure de base des règles de sécurité. Combinez cette syntaxe avec des conditions de règles de sécurité pour créer des ensembles de règles complets.

Déclaration de service et de base de données

Les règles de sécurité Cloud Firestore commencent toujours par la déclaration suivante :

service cloud.firestore {
  match /databases/{database}/documents {
    // ...
  }
}

La déclaration service cloud.firestore les règles à Cloud Firestore, évitant ainsi les conflits entre les règles de sécurité Cloud Firestore et les règles d'autres produits tels que Cloud Storage.

La déclaration match /databases/{database}/documents spécifie que les règles doivent correspondre à n'importe quelle base de données Cloud Firestore du projet. Actuellement, chaque projet n'a qu'une seule base de données nommée (default) .

Règles de lecture/écriture de base

Les règles de base consistent en une instruction match spécifiant un chemin de document et une expression allow détaillant quand la lecture des données spécifiées est autorisée :

service cloud.firestore {
  match /databases/{database}/documents {

    // Match any document in the 'cities' collection
    match /cities/{city} {
      allow read: if <condition>;
      allow write: if <condition>;
    }
  }
}

Toutes les instructions de correspondance doivent pointer vers des documents, et non vers des collections. Une instruction match peut pointer vers un document spécifique, comme dans match /cities/SF ou utiliser des caractères génériques pour pointer vers n'importe quel document dans le chemin spécifié, comme dans match /cities/{city} .

Dans l'exemple ci-dessus, l'instruction match utilise la syntaxe générique {city} . Cela signifie que la règle s'applique à tout document de la collection cities , comme /cities/SF ou /cities/NYC . Lorsque les expressions d' allow dans l'instruction de correspondance sont évaluées, la variable city sera résolue en nom de document de ville, tel que SF ou NYC .

Opérations granulaires

Dans certaines situations, il est utile de décomposer la read et l' write en opérations plus granulaires. Par exemple, votre application peut vouloir appliquer des conditions différentes sur la création de documents que sur la suppression de documents. Ou vous pouvez autoriser la lecture d'un seul document mais refuser les requêtes volumineuses.

Une règle de read peut être décomposée en get et list , tandis qu'une règle d' write peut être décomposée en create , update et delete :

service cloud.firestore {
  match /databases/{database}/documents {
    // A read rule can be divided into get and list rules
    match /cities/{city} {
      // Applies to single document read requests
      allow get: if <condition>;

      // Applies to queries and collection read requests
      allow list: if <condition>;
    }

    // A write rule can be divided into create, update, and delete rules
    match /cities/{city} {
      // Applies to writes to nonexistent documents
      allow create: if <condition>;

      // Applies to writes to existing documents
      allow update: if <condition>;

      // Applies to delete operations
      allow delete: if <condition>;
    }
  }
}

Données hiérarchiques

Les données dans Cloud Firestore sont organisées en collections de documents, et chaque document peut étendre la hiérarchie via des sous-collections. Il est important de comprendre comment les règles de sécurité interagissent avec les données hiérarchiques.

Considérez la situation où chaque document de la collection de cities contient une sous-collection de points de landmarks . Les règles de sécurité s'appliquent uniquement au chemin correspondant, de sorte que les contrôles d'accès définis sur la collection cities ne s'appliquent pas à la sous-collection landmarks . Écrivez plutôt des règles explicites pour contrôler l'accès aux sous-collections :

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

Lors de l'imbrication d'instructions de match , le chemin de l'instruction de match interne est toujours relatif au chemin de l'instruction de match externe. Les ensembles de règles suivants sont donc équivalents :

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

Caractères génériques récursifs

Si vous souhaitez que les règles s'appliquent à une hiérarchie arbitrairement profonde, utilisez la syntaxe générique récursive, {name=**} . Par exemple:

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

Lors de l'utilisation de la syntaxe générique récursive, la variable générique contiendra l'intégralité du segment de chemin correspondant, même si le document se trouve dans une sous-collection profondément imbriquée. Par exemple, les règles répertoriées ci-dessus correspondraient à un document situé dans /cities/SF/landmarks/coit_tower , et la valeur de la variable document serait SF/landmarks/coit_tower .

Notez cependant que le comportement des caractères génériques récursifs dépend de la version des règles.

Version 1

Les règles de sécurité utilisent la version 1 par défaut. Dans la version 1, les caractères génériques récursifs correspondent à un ou plusieurs éléments de chemin. Ils ne correspondent pas à un chemin vide, donc match /cities/{city}/{document=**} correspond aux documents dans les sous-collections mais pas dans la collection cities , alors que match /cities/{document=**} correspond aux deux documents dans le collections et sous-collections des cities .

Les caractères génériques récursifs doivent figurer à la fin d'une instruction de correspondance.

Version 2

Dans la version 2 des règles de sécurité, les caractères génériques récursifs correspondent à zéro ou plusieurs éléments de chemin. match/cities/{city}/{document=**} correspond aux documents de toutes les sous-collections ainsi qu'aux documents de la collection de cities .

Vous devez vous inscrire à la version 2 en ajoutant rules_version = '2'; au sommet de vos règles de sécurité :

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

Vous pouvez avoir au plus un caractère générique récursif par instruction de correspondance, mais dans la version 2, vous pouvez placer ce caractère générique n'importe où dans l'instruction de correspondance. Par exemple:

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

Si vous utilisez des requêtes de groupe de collections , vous devez utiliser la version 2, voir sécurisation des requêtes de groupe de collections .

Chevauchement des déclarations de correspondance

Il est possible qu'un document corresponde à plusieurs instructions de match . Dans le cas où plusieurs expressions d' allow correspondent à une requête, l'accès est autorisé si l'une des conditions est true :

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

Dans l'exemple ci-dessus, toutes les lectures et écritures dans la collection cities seront autorisées car la deuxième règle est toujours true , même si la première règle est toujours false .

Limites des règles de sécurité

Lorsque vous travaillez avec des règles de sécurité, notez les limites suivantes :

Limite Détails
Nombre maximal d'appels exists() , get() et getAfter() par requête
  • 10 pour les demandes de document unique et les demandes de requête.
  • 20 pour les lectures de plusieurs documents, les transactions et les écritures par lots. La limite précédente de 10 s'applique également à chaque opération.

    Par exemple, imaginez que vous créez une demande d'écriture par lot avec 3 opérations d'écriture et que vos règles de sécurité utilisent 2 appels d'accès aux documents pour valider chaque écriture. Dans ce cas, chaque écriture utilise 2 de ses 10 appels d'accès et la demande d'écriture groupée utilise 6 de ses 20 appels d'accès.

Le dépassement de l'une ou l'autre des limites entraîne une erreur d'autorisation refusée.

Certains appels d'accès aux documents peuvent être mis en cache et les appels mis en cache ne sont pas pris en compte dans les limites.

Profondeur maximale de l'instruction de match imbriquée dix
Longueur maximale du chemin, en segments de chemin, autorisée dans un ensemble d'instructions de match imbriquées 100
Nombre maximal de variables de capture de chemin autorisées dans un ensemble d'instructions de match imbriquées 20
Profondeur maximale d'appel de fonction 20
Nombre maximal d'arguments de fonction sept
Nombre maximal de liaisons de variables let par fonction dix
Nombre maximal d'appels de fonction récursifs ou cycliques 0 (non autorisé)
Nombre maximal d'expressions évaluées par requête 1 000
Taille maximale d'un jeu de règles Les ensembles de règles doivent respecter deux limites de taille :
  • une limite de 256 Ko sur la taille de la source de texte de l'ensemble de règles publié à partir de la console Firebase ou de la CLI à l'aide de firebase deploy .
  • une limite de 250 Ko sur la taille de l'ensemble de règles compilé qui se produit lorsque Firebase traite la source et la rend active sur le back-end.

Prochaines étapes