Règles de sécurité et authentification Firebase

Les règles de sécurité Firebase fournissent le contrôle d'accès et la validation des données dans un format qui prend en charge plusieurs niveaux de complexité. Pour construire des systèmes d'accès et basés sur les rôles basés sur les utilisateurs qui maintiennent la sécurité des données de vos utilisateurs, utilisez Firebase authentification avec Firebase règles de sécurité.

Identifier les utilisateurs

L'authentification identifie les utilisateurs qui demandent l'accès à vos données et fournit ces informations en tant que variable que vous pouvez exploiter dans vos règles. La auth variable contient les informations suivantes:

  • uid : Un identifiant d'utilisateur unique attribué à l'utilisateur demandeur.
  • token : Une carte des valeurs recueillies par l' authentification.

La auth.token variable contient les valeurs suivantes:

Domaine La description
email L'adresse e-mail associée au compte, le cas échéant.
email_verified true si l'utilisateur a vérifié qu'ils ont accès à l' email adresse. Certains fournisseurs vérifient automatiquement les adresses e-mail qu'ils possèdent.
phone_number Le numéro de téléphone associé au compte, s'il est présent.
name Le nom d'affichage de l'utilisateur, s'il est défini.
sub L'UID Firebase de l'utilisateur. C'est unique dans un projet.
firebase.identities Dictionnaire de toutes les identités associées au compte de cet utilisateur. Les clés du dictionnaire peut être l' un des suivants: email , phone , google.com , facebook.com , github.com , twitter.com . Les valeurs du dictionnaire sont des tableaux d'identifiants uniques pour chaque fournisseur d'identité associé au compte. Par exemple, auth.token.firebase.identities["google.com"][0] contient le premier code d'utilisateur Google associé au compte.
firebase.sign_in_provider Le fournisseur de connexion utilisé pour obtenir ce jeton. Peut - être l' une des chaînes suivantes: custom , password de phone anonymous google.com facebook.com github.com twitter.com password , phone , anonymous , google.com , facebook.com , github.com , twitter.com .

Si vous voulez ajouter des attributs d'authentification personnalisés, la auth.token variable contient également des demandes personnalisées que vous spécifiez.

Lorsque l'accès utilisateur demande n'est pas connecté, la auth variable est null . Vous pouvez tirer parti dans vos règles si, par exemple, vous souhaitez limiter l' accès en lecture aux utilisateurs authentifiés - auth != null . Cependant, nous recommandons généralement de limiter davantage l'accès en écriture.

Pour plus d' informations sur la auth variables, consultez la documentation de référence pour Nuage Firestore , Base de données en temps réel et Cloud Storage .

Exploiter les informations utilisateur dans les règles

En pratique, l'utilisation d'informations authentifiées dans vos règles rend vos règles plus puissantes et plus flexibles. Vous pouvez contrôler l'accès aux données en fonction de l'identité de l'utilisateur.

Dans vos règles, définir comment les informations contenues dans la auth variable - les informations utilisateur du demandeur - correspond à l'information de l' utilisateur associé aux données demandées.

Par exemple, votre application peut vouloir s'assurer que les utilisateurs ne peuvent lire et écrire que leurs propres données. Dans ce scénario, vous voulez un match entre la auth.uid variable et l'ID utilisateur sur les données demandées:

Cloud Firestore

service cloud.firestore {
  match /databases/{database}/documents {
    // Make sure the uid of the requesting user matches name of the user
    // document. The wildcard expression {userId} makes the userId variable
    // available in rules.
    match /users/{userId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
  }
}

Base de données en temps réel

{
  "rules": {
    "users": {
      "$userId": {
        // grants write access to the owner of this user account
        // whose uid must exactly match the key ($userId)
        ".write": "$userId === auth.uid"
      }
    }
  }
}

Stockage en ligne

service firebase.storage {
  // Only a user can upload their file, but anyone can view it
  match /users/{userId}/{fileName} {
    allow read;
    allow write: if request.auth != null && request.auth.uid == userId;
  }
}

Définir des informations utilisateur personnalisées

Vous pouvez continuer à tirer parti de la auth variable pour définir les champs personnalisés attribués aux utilisateurs de votre application.

Par exemple, supposons que vous souhaitiez créer un rôle « admin » qui autorise l'accès en écriture sur certains chemins. Vous attribueriez cet attribut aux utilisateurs, puis vous en tireriez parti dans les règles accordant l'accès aux chemins.

Dans Cloud Firestore, vous pouvez ajouter un champ personnalisé aux documents des utilisateurs et récupérer la valeur de ce champ avec une lecture intégrée dans vos règles. Ainsi, votre règle basée sur l'administrateur ressemblerait à l'exemple suivant :

Cloud Firestore

service cloud.firestore {
  match /databases/{database}/documents/some_collection: {
    // Remember that, in Cloud Firestore, reads embedded in your rules are billed operations
    write: if request.auth != null && get(/databases/(database)/documents/users/$(request.auth.uid)).data.admin) == true;
    read: if request.auth != null;
  }
}

Pour les règles en temps réel et la base de données Cloud Storage, créer les revendications personnalisées dans l' authentification. Vous pouvez ensuite référencer ces revendications personnalisées à l' aide de la auth.token variable.

Base de données en temps réel

{
  "rules": {
    "some_path/$sub_path": {
      // Create a custom claim for the admin role
      ".write": "auth.uid != null && auth.token.writer == true"
      ".read": "auth.uid != null"
      }
    }
  }

Stockage en ligne

service firebase.storage {
  // Create a custom claim for the admin role
  match /files/{fileName} {
    allow read: if request.auth.uid != null;
    allow write: if request.auth.token.admin == true;
  }
}

Pour voir d' autres exemples de règles de base d' authentification tirant parti, voir les règles de sécurité de base .