Règles de sécurité de base

Les Firebase Security Rules vous permettent de contrôler l'accès à vos données stockées. Règles flexibles vous pouvez créer des règles qui correspondent à n'importe quel élément, de toutes les écritures l'intégralité de la base de données aux opérations sur un document spécifique.

Ce guide décrit certains des cas d'utilisation les plus élémentaires lorsque vous configurez votre application et protégez vos données. Toutefois, avant de commencer à écrire des règles, vous pouvez en savoir plus sur le langage dans lequel elles sont écrites et sur leur comportement.

Pour accéder à vos règles et les mettre à jour, suivez les étapes décrites dans Gérez et déployez Firebase Security Rules.

Règles par défaut: mode verrouillé

Lorsque vous créez une base de données ou une instance de stockage dans la console Firebase, vous choisissez si votre Firebase Security Rules limite ou non l'accès à vos données (mode verrouillé) ou autoriser tout le monde à y accéder (mode test). Dans Cloud Firestore et Realtime Database, les règles par défaut du mode verrouillé refusent l'accès à tous les utilisateurs. Dans Cloud Storage, seuls les utilisateurs authentifiés peuvent accéder aux buckets de stockage.

service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if false;
    }
  }
}

{
  "rules": {
    ".read": false,
    ".write": false
  }
}

service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write: if request.auth != null;
    }
  }
}

Règles d'environnement de développement

Lorsque vous travaillez sur votre application, vous pouvez choisir de rester relativement ouvert ou libre l'accès à vos données. Pensez simplement à mettre à jour votre Rules avant le vous déploierez votre application en production. N'oubliez pas non plus que si vous déployez votre application, elle est accessible publiquement, même si vous ne l'avez pas lancée.

Firebase permet aux clients d'accéder directement à vos données Firebase Security Rules est la seule protection qui bloque l'accès des utilisateurs malveillants. La définition de règles distinctes de la logique produit présente un certain nombre d'avantages : les clients ne sont pas responsables de l'application de la sécurité, les implémentations défectueuses ne compromettent pas vos données et, surtout, vous ne dépendez pas d'un serveur intermédiaire pour protéger les données du monde extérieur.

Tous les utilisateurs authentifiés

Bien que nous vous recommandions de ne pas laisser vos données accessibles aux utilisateurs connecté, il peut être utile de définir l'accès à n'importe quel utilisateur authentifié lorsque vous développez votre application.

service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if request.auth != null;
    }
  }
}

{
  "rules": {
    ".read": "auth.uid !== null",
    ".write": "auth.uid !== null"
  }
}

service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write: if request.auth != null;
    }
  }
}

Règles prêtes pour la production

Lorsque vous préparez le déploiement de votre application, assurez-vous que vos données sont protégées et que l'accès est correctement accordé à vos utilisateurs. Utilisez Authentication pour configurer l'accès basé sur l'utilisateur et lisez directement à partir de votre base de données pour configurer l'accès basé sur les données.

Envisagez d'écrire des règles lorsque vous structurez vos données, car la façon dont vous configurez vos règles a une incidence sur la façon dont vous limitez l'accès aux données sur différents chemins.

Accès limité au propriétaire du contenu

Ces règles limitent l'accès au propriétaire authentifié du contenu uniquement. La données ne sont lisibles et accessibles en écriture que par un seul utilisateur, et le chemin d'accès aux données contient de l'utilisateur.

Quand cette règle fonctionne : cette règle fonctionne bien si les données sont cloisonnées par utilisateur, c'est-à-dire si le seul utilisateur qui a besoin d'accéder aux données est celui qui les a créées.

Lorsque cette règle ne fonctionne pas:l'ensemble de règles ne fonctionne pas lorsque plusieurs utilisateurs doivent écrire ou lire les mêmes données. Les utilisateurs les écraseront ou ne pourront pas pour accéder aux données qu'il a créées.

Pour configurer cette règle:créez-en une qui confirme l'utilisateur qui demande l'accès. pour lire ou écrire des données est l'utilisateur qui détient ces données.

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow only authenticated content owners access
    match /some_collection/{userId}/{documents=**} {
      allow read, write: if request.auth != null && request.auth.uid == userId
    }
  }
}

{
  "rules": {
    "some_path": {
      "$uid": {
        // Allow only authenticated content owners access to their data
        ".read": "auth !== null && auth.uid === $uid",
        ".write": "auth !== null && auth.uid === $uid"
      }
    }
  }
}

// Grants a user access to a node matching their user ID
service firebase.storage {
  match /b/{bucket}/o {
    // Files look like: "user/<UID>/path/to/file.txt"
    match /user/{userId}/{allPaths=**} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
  }
}

Accès public et privé mixte

Cette règle permet à quiconque de lire un ensemble de données, mais limite la possibilité de créer ou modifier des données à un chemin d'accès donné au propriétaire de contenu authentifié uniquement.

Lorsque cette règle fonctionne:elle fonctionne bien pour les applications qui nécessitent un accès des éléments lisibles, mais que vous devez restreindre l'accès en modification à ces éléments propriétaires. Par exemple, une application de chat ou un blog.

Lorsque cette règle ne fonctionne pas:comme la règle "Propriétaire de contenu uniquement", cet ensemble de règles ne fonctionne pas lorsque plusieurs utilisateurs doivent modifier les mêmes données. Les utilisateurs finiront par écraser les données des uns et des autres.

Pour configurer cette règle:créez une règle qui autorise l'accès en lecture pour tous les utilisateurs. (ou tous les utilisateurs authentifiés), et confirme que l'utilisateur qui écrit les données en est le propriétaire.

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow public read access, but only content owners can write
    match /some_collection/{document} {
      allow read: if true
      allow create: if request.auth.uid == request.resource.data.author_uid;
      allow update, delete: if request.auth.uid == resource.data.author_uid;
    }
  }
}

{
// Allow anyone to read data, but only authenticated content owners can
// make changes to their data

  "rules": {
    "some_path": {
      "$uid": {
        ".read": true,
        // or ".read": "auth.uid !== null" for only authenticated users
        ".write": "auth.uid === $uid"
      }
    }
  }
}

service firebase.storage {
  match /b/{bucket}/o {
    // Files look like: "user/<UID>/path/to/file.txt"
    match /user/{userId}/{allPaths=**} {
      allow read;
      allow write: if request.auth.uid == userId;
    }
  }
}

Accès basé sur les attributs et les rôles

Pour que ces règles fonctionnent, vous devez définir et attribuer des attributs aux utilisateurs dans vos données. Firebase Security Rules compare la requête aux données de votre base de données ou de votre fichier pour confirmer ou refuser l'accès.

Lorsque cette règle fonctionne:si vous attribuez un rôle à des utilisateurs, cette règle il est facile de limiter l'accès en fonction de rôles ou de groupes d'utilisateurs spécifiques. Par exemple, si vous stockiez les notes, vous pouvez attribuer différents niveaux d'accès "élèves" (lecture seule), les "enseignants" groupe (lire et écrivez dans leur sujet), et les "directeurs" groupe (lire tout le contenu).

Quand cette règle ne fonctionne pas : dans Realtime Database et Cloud Storage, vos règles ne peuvent pas exploiter la méthode get() que les règles Cloud Firestore peuvent intégrer. Par conséquent, vous devez structurer les métadonnées de votre base de données ou de votre fichier pour refléter les attributs que vous utilisez dans vos règles.

Pour configurer cette règle:dans Cloud Firestore, incluez un champ dans l'onglet des documents lisibles, puis structurez votre règle pour qu'elle lise ces et accordez l'accès sous condition. Dans Realtime Database, créez un chemin d'accès aux données qui définit les utilisateurs de votre application et leur attribue un rôle dans un nœud enfant.

Vous pouvez également configurer des revendications personnalisées dans Authentication. puis vous récupérez ces informations la variable auth.token dans n'importe quel Firebase Security Rules.

Attributs et rôles définis par les données

Ces règles ne fonctionnent que dans Cloud Firestore et Realtime Database.

service cloud.firestore {
  match /databases/{database}/documents {
    // For attribute-based access control, Check a boolean `admin` attribute
    allow write: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.admin == true;
    allow read: true;

    // Alterntatively, for role-based access, assign specific roles to users
    match /some_collection/{document} {
     allow read: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Reader"
     allow write: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Writer"
   }
  }
}

{
  "rules": {
    "some_path": {
      "${subpath}": {
        //
        ".write": "root.child('users').child(auth.uid).child('role').val() === 'admin'",
        ".read": true
      }
    }
  }
}

Attributs et rôles de revendication personnalisée

Pour appliquer ces règles, configurez des revendications personnalisées. dans Firebase Authentication, puis utilisez les revendications dans vos règles.

service cloud.firestore {
  match /databases/{database}/documents {
    // For attribute-based access control, check for an admin claim
    allow write: if request.auth.token.admin == true;
    allow read: true;

    // Alterntatively, for role-based access, assign specific roles to users
    match /some_collection/{document} {
     allow read: if request.auth.token.reader == "true";
     allow write: if request.auth.token.writer == "true";
   }
  }
}

{
  "rules": {
    "some_path": {
      "$uid": {
        // Create a custom claim for each role or group
        // you want to leverage
        ".write": "auth.uid !== null && auth.token.writer === true",
        ".read": "auth.uid !== null && auth.token.reader === true"
      }
    }
  }
}

service firebase.storage {
  // Allow reads if the group ID in your token matches the file metadata's `owner` property
  // Allow writes if the group ID is in the user's custom token
  match /files/{groupId}/{fileName} {
    allow read: if resource.metadata.owner == request.auth.token.groupId;
    allow write: if request.auth.token.groupId == groupId;
  }
}

Attributs de location

Pour implémenter ces règles, configurez une architecture mutualisée dans Google Cloud Identity Platform (GCIP) puis d'exploiter le locataire dans vos règles. Les exemples suivants autorisent les écritures d'un utilisateur appartenant à un locataire spécifique, par exemple tenant2-m6tyz

service cloud.firestore {
  match /databases/{database}/documents {
    // For tenant-based access control, check for a tenantID
    allow write: if request.auth.token.firebase.tenant == 'tenant2-m6tyz';
    allow read: true;
  }
}

{
  "rules": {
    "some_path": {
      "$uid": {
        // Only allow reads and writes if user belongs to a specific tenant
        ".write": "auth.uid !== null && auth.token.firebase.tenant === 'tenant2-m6tyz'",
        ".read": "auth.uid !== null
      }
    }
  }
}

service firebase.storage {
  // Only allow reads and writes if user belongs to a specific tenant
  match /files/{tenantId}/{fileName} {
    allow read: if request.auth != null;
    allow write: if request.auth.token.firebase.tenant == tenantId;
  }
}