Interroger les données en toute sécurité

Cette page s'appuie sur les concepts de Structuration des règles de sécurité et d'écriture des conditions pour les règles de sécurité pour expliquer comment les règles de sécurité Cloud Firestore interagissent avec les requêtes. Il examine de plus près la façon dont les règles de sécurité affectent les requêtes que vous pouvez écrire et décrit comment garantir que vos requêtes utilisent les mêmes contraintes que vos règles de sécurité. Cette page décrit également comment écrire des règles de sécurité pour autoriser ou refuser les requêtes en fonction de propriétés de requête telles que limit et orderBy .

Les règles ne sont pas des filtres

Lorsque vous rédigez des requêtes pour récupérer des documents, gardez à l’esprit que les règles de sécurité ne sont pas des filtres : les requêtes sont tout ou rien. Pour vous faire gagner du temps et des ressources, Cloud Firestore évalue une requête par rapport à son ensemble de résultats potentiels au lieu des valeurs réelles des champs pour tous vos documents. Si une requête est susceptible de renvoyer des documents que le client n'est pas autorisé à lire, la requête entière échoue.

Requêtes et règles de sécurité

Comme le démontrent les exemples ci-dessous, vous devez rédiger vos requêtes pour répondre aux contraintes de vos règles de sécurité.

Sécurisez et interrogez des documents basés sur auth.uid

L'exemple suivant montre comment écrire une requête pour récupérer des documents protégés par une règle de sécurité. Prenons l'exemple d'une base de données contenant une collection de documents story :

/histoires/{identifiant de l'histoire}

{
  title: "A Great Story",
  content: "Once upon a time...",
  author: "some_auth_id",
  published: false
}

En plus des champs title et content , chaque document stocke les champs author et published à utiliser pour le contrôle d'accès. Ces exemples supposent que l'application utilise l'authentification Firebase pour définir le champ author sur l'UID de l'utilisateur qui a créé le document. L'authentification Firebase renseigne également la variable request.auth dans les règles de sécurité.

La règle de sécurité suivante utilise les variables request.auth et resource.data pour restreindre l'accès en lecture et en écriture de chaque story à son auteur :

service cloud.firestore {
  match /databases/{database}/documents {
    match /stories/{storyid} {
      // Only the authenticated user who authored the document can read or write
      allow read, write: if request.auth != null && request.auth.uid == resource.data.author;
    }
  }
}

Supposons que votre application inclut une page qui montre à l’utilisateur une liste de documents story qu’il a créés. Vous pourriez vous attendre à pouvoir utiliser la requête suivante pour remplir cette page. Cependant, cette requête échouera, car elle n'inclut pas les mêmes contraintes que vos règles de sécurité :

Invalide : les contraintes de requête ne correspondent pas aux contraintes des règles de sécurité

// This query will fail
db.collection("stories").get()

La requête échoue même si l'utilisateur actuel est en réalité l'auteur de chaque document story . La raison de ce comportement est que lorsque Cloud Firestore applique vos règles de sécurité, il évalue la requête par rapport à son ensemble de résultats potentiels , et non par rapport aux propriétés réelles des documents de votre base de données. Si une requête est susceptible d'inclure des documents qui violent vos règles de sécurité, la requête échouera.

En revanche, la requête suivante réussit, car elle inclut la même contrainte sur le champ author que les règles de sécurité :

Valide : les contraintes de requête correspondent aux contraintes des règles de sécurité

var user = firebase.auth().currentUser;

db.collection("stories").where("author", "==", user.uid).get()

Sécurisez et interrogez des documents en fonction d'un champ

Pour démontrer davantage l'interaction entre les requêtes et les règles, les règles de sécurité ci-dessous étendent l'accès en lecture à la collection stories pour permettre à tout utilisateur de lire les documents story où le champ published est défini sur true .

service cloud.firestore {
  match /databases/{database}/documents {
    match /stories/{storyid} {
      // Anyone can read a published story; only story authors can read unpublished stories
      allow read: if resource.data.published == true || (request.auth != null && request.auth.uid == resource.data.author);
      // Only story authors can write
      allow write: if request.auth != null && request.auth.uid == resource.data.author;
    }
  }
}

La requête des pages publiées doit inclure les mêmes contraintes que les règles de sécurité :

db.collection("stories").where("published", "==", true).get()

La contrainte de requête .where("published", "==", true) garantit que resource.data.published est true pour tout résultat. Par conséquent, cette requête satisfait aux règles de sécurité et est autorisée à lire des données.

OR requêtes

Lors de l'évaluation d'une requête OR logique ( or , in ou array-contains-any ) par rapport à un ensemble de règles, Cloud Firestore évalue chaque valeur de comparaison séparément. Chaque valeur de comparaison doit répondre aux contraintes des règles de sécurité. Par exemple, pour la règle suivante :

match /mydocuments/{doc} {
  allow read: if resource.data.x > 5;
}

Invalide : la requête ne garantit pas que x > 5 pour tous les documents potentiels

// These queries will fail
query(db.collection("mydocuments"),
      or(where("x", "==", 1),
         where("x", "==", 6)
      )
    )

query(db.collection("mydocuments"),
      where("x", "in", [1, 3, 6, 42, 99])
    )

Valide : la requête garantit que x > 5 pour tous les documents potentiels

query(db.collection("mydocuments"),
      or(where("x", "==", 6),
         where("x", "==", 42)
      )
    )

query(db.collection("mydocuments"),
      where("x", "in", [6, 42, 99, 105, 200])
    )

Évaluation des contraintes sur les requêtes

Vos règles de sécurité peuvent également accepter ou refuser des requêtes en fonction de leurs contraintes. La variable request.query contient les limit , offset et orderBy d'une requête. Par exemple, vos règles de sécurité peuvent refuser toute requête qui ne limite pas le nombre maximum de documents récupérés à une certaine plage :

allow list: if request.query.limit <= 10;

L'ensemble de règles suivant montre comment écrire des règles de sécurité qui évaluent les contraintes imposées aux requêtes. Cet exemple étend l'ensemble de règles stories précédentes avec les modifications suivantes :

  • L'ensemble de règles sépare la règle de lecture en règles pour get et list .
  • La règle get limite la récupération de documents uniques aux documents publics ou aux documents créés par l'utilisateur.
  • La règle list applique les mêmes restrictions que get mais pour les requêtes. Il vérifie également la limite de requêtes, puis refuse toute requête sans limite ou avec une limite supérieure à 10.
  • L'ensemble de règles définit une fonction authorOrPublished() pour éviter la duplication de code.
service cloud.firestore {

  match /databases/{database}/documents {

    match /stories/{storyid} {

      // Returns `true` if the requested story is 'published'
      // or the user authored the story
      function authorOrPublished() {
        return resource.data.published == true || request.auth.uid == resource.data.author;
      }

      // Deny any query not limited to 10 or fewer documents
      // Anyone can query published stories
      // Authors can query their unpublished stories
      allow list: if request.query.limit <= 10 &&
                     authorOrPublished();

      // Anyone can retrieve a published story
      // Only a story's author can retrieve an unpublished story
      allow get: if authorOrPublished();

      // Only a story's author can write to a story
      allow write: if request.auth.uid == resource.data.author;
    }

  }
}

Requêtes de groupe de collecte et règles de sécurité

Par défaut, les requêtes sont limitées à une seule collection et récupèrent uniquement les résultats de cette collection. Avec les requêtes de groupe de collections , vous pouvez récupérer les résultats d'un groupe de collections composé de toutes les collections portant le même ID. Cette section décrit comment sécuriser vos requêtes de groupe de collecte à l'aide de règles de sécurité.

Sécurisez et interrogez des documents en fonction de groupes de collections

Dans vos règles de sécurité, vous devez autoriser explicitement les requêtes de groupe de collecte en écrivant une règle pour le groupe de collecte :

  1. Assurez-vous que rules_version = '2'; est la première ligne de votre ensemble de règles. Les requêtes de groupe de collecte nécessitent le nouveau comportement de caractère générique récursif {name=**} des règles de sécurité version 2.
  2. Écrivez une règle pour votre groupe de collecte en utilisant match /{path=**}/ [COLLECTION_ID] /{doc} .

Par exemple, considérons un forum organisé en documents forum contenant des sous-collections posts :

/forums/{forumid}/posts/{postid}

{
  author: "some_auth_id",
  authorname: "some_username",
  content: "I just read a great story.",
}

Dans cette application, nous rendons les publications modifiables par leurs propriétaires et lisibles par les utilisateurs authentifiés :

service cloud.firestore {
  match /databases/{database}/documents {
    match /forums/{forumid}/posts/{post} {
      // Only authenticated users can read
      allow read: if request.auth != null;
      // Only the post author can write
      allow write: if request.auth != null && request.auth.uid == resource.data.author;
    }
  }
}

Tout utilisateur authentifié peut récupérer les messages de n'importe quel forum :

db.collection("forums/technology/posts").get()

Mais que se passe-t-il si vous souhaitez montrer à l'utilisateur actuel ses publications sur tous les forums ? Vous pouvez utiliser une requête de groupe de collections pour récupérer les résultats de toutes les collections posts :

var user = firebase.auth().currentUser;

db.collectionGroup("posts").where("author", "==", user.uid).get()

Dans vos règles de sécurité, vous devez autoriser cette requête en écrivant une règle de lecture ou de liste pour le groupe de collecte posts :

rules_version = '2';
service cloud.firestore {

  match /databases/{database}/documents {
    // Authenticated users can query the posts collection group
    // Applies to collection queries, collection group queries, and
    // single document retrievals
    match /{path=**}/posts/{post} {
      allow read: if request.auth != null;
    }
    match /forums/{forumid}/posts/{postid} {
      // Only a post's author can write to a post
      allow write: if request.auth != null && request.auth.uid == resource.data.author;

    }
  }
}

Notez cependant que ces règles s'appliqueront à toutes les collections avec posts ID, quelle que soit la hiérarchie. Par exemple, ces règles s'appliquent à toutes les collections posts suivantes :

  • /posts/{postid}
  • /forums/{forumid}/posts/{postid}
  • /forums/{forumid}/subforum/{subforumid}/posts/{postid}

Requêtes de groupe de collecte sécurisée basées sur un champ

Comme les requêtes à collection unique, les requêtes de groupe de collections doivent également répondre aux contraintes définies par vos règles de sécurité. Par exemple, nous pouvons ajouter un champ published à chaque message du forum, comme nous l'avons fait dans l'exemple stories ci-dessus :

/forums/{forumid}/posts/{postid}

{
  author: "some_auth_id",
  authorname: "some_username",
  content: "I just read a great story.",
  published: false
}

Nous pouvons ensuite écrire des règles pour le groupe de collecte posts en fonction du statut published et de l' author de la publication :

rules_version = '2';
service cloud.firestore {

  match /databases/{database}/documents {

    // Returns `true` if the requested post is 'published'
    // or the user authored the post
    function authorOrPublished() {
      return resource.data.published == true || request.auth.uid == resource.data.author;
    }

    match /{path=**}/posts/{post} {

      // Anyone can query published posts
      // Authors can query their unpublished posts
      allow list: if authorOrPublished();

      // Anyone can retrieve a published post
      // Authors can retrieve an unpublished post
      allow get: if authorOrPublished();
    }

    match /forums/{forumid}/posts/{postid} {
      // Only a post's author can write to a post
      allow write: if request.auth.uid == resource.data.author;
    }
  }
}

Avec ces règles, les clients Web, Apple et Android peuvent effectuer les requêtes suivantes :

  • Tout le monde peut récupérer les messages publiés dans un forum :

    db.collection("forums/technology/posts").where('published', '==', true).get()

  • N'importe qui peut récupérer les messages publiés par un auteur sur tous les forums :

    db.collectionGroup("posts").where("author", "==", "some_auth_id").where('published', '==', true).get()

  • Les auteurs peuvent récupérer tous leurs articles publiés et non publiés sur tous les forums :

    var user = firebase.auth().currentUser;

db.collectionGroup("posts").where("author", "==", user.uid).get()

Sécurisez et interrogez les documents en fonction du groupe de collecte et du chemin du document

Dans certains cas, vous souhaiterez peut-être restreindre les requêtes des groupes de collections en fonction du chemin du document. Pour créer ces restrictions, vous pouvez utiliser les mêmes techniques de sécurisation et d'interrogation de documents en fonction d'un champ.

Prenons l'exemple d'une application qui assure le suivi des transactions de chaque utilisateur entre plusieurs bourses d'actions et de crypto-monnaie :

/users/{userid}/exchange/{exchangeid}/transactions/{transaction}

{
  amount: 100,
  exchange: 'some_exchange_name',
  timestamp: April 1, 2019 at 12:00:00 PM UTC-7,
  user: "some_auth_id",
}

Notez le champ user . Même si nous savons quel utilisateur possède un document transaction grâce au chemin du document, nous dupliquons cette information dans chaque document transaction car cela nous permet de faire deux choses :

  • Écrivez des requêtes de groupe de collection limitées aux documents qui incluent un /users/{userid} spécifique dans leur chemin de document. Par exemple:

    var user = firebase.auth().currentUser;
// Return current user's last five transactions across all exchanges
db.collectionGroup("transactions").where("user", "==", user).orderBy('timestamp').limit(5)

  • Appliquez cette restriction pour toutes les requêtes sur le groupe de collecte transactions afin qu'un utilisateur ne puisse pas récupérer les documents transaction d'un autre utilisateur.

Nous appliquons cette restriction dans nos règles de sécurité et incluons la validation des données pour le champ user :

rules_version = '2';
service cloud.firestore {

  match /databases/{database}/documents {

    match /{path=**}/transactions/{transaction} {
      // Authenticated users can retrieve only their own transactions
      allow read: if resource.data.user == request.auth.uid;
    }

    match /users/{userid}/exchange/{exchangeid}/transactions/{transaction} {
      // Authenticated users can write to their own transactions subcollections
      // Writes must populate the user field with the correct auth id
      allow write: if userid == request.auth.uid && request.data.user == request.auth.uid
    }
  }
}

Prochaines étapes