Règles de sécurité de base

Les règles de sécurité Firebase vous permettent de contrôler l'accès à vos données stockées. La syntaxe flexible des règles signifie que vous pouvez créer des règles qui correspondent à tout, depuis toutes les écritures dans l'ensemble de la base de données jusqu'aux opérations sur un document spécifique.

Ce guide décrit certains des cas d'utilisation les plus élémentaires que vous souhaiterez peut-être mettre en œuvre lors de la configuration de votre application et de la protection de vos données. Cependant, avant de commencer à écrire des règles, vous souhaiterez peut-être en savoir plus sur le langage dans lequel elles sont écrites et sur leur comportement .

Pour accéder et mettre à jour vos règles, suivez les étapes décrites dans Gérer et déployer les règles de sécurité Firebase .

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 vos règles de sécurité Firebase restreignent l'accès à vos données ( Mode verrouillé ) ou autorisent l'accès à quiconque ( 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

Pendant que vous travaillez sur votre application, vous souhaiterez peut-être un accès relativement ouvert ou sans entrave à vos données. Assurez-vous simplement de mettre à jour vos règles avant de déployer votre application en production. N'oubliez pas non plus que si vous déployez votre application, elle est accessible au public, même si vous ne l'avez pas lancée .

N'oubliez pas que Firebase permet aux clients d'accéder directement à vos données et que les règles de sécurité Firebase sont la seule protection bloquant l'accès des utilisateurs malveillants. Définir des règles séparément de la logique du produit présente de nombreux avantages : les clients ne sont pas responsables du respect de la sécurité, des implémentations boguées ne compromettront pas vos données et, plus important encore, vous ne comptez pas sur un serveur intermédiaire pour protéger les données du monde.

Tous les utilisateurs authentifiés

Bien que nous ne recommandons pas de laisser vos données accessibles à tout utilisateur connecté, il peut être utile de définir l'accès à tout utilisateur authentifié pendant que 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. Tirez parti de l'authentification pour configurer l'accès basé sur les utilisateurs et lisez directement à partir de votre base de données pour configurer l'accès basé sur les données.

Pensez à écrire des règles lorsque vous structurez vos données, car la façon dont vous configurez vos règles a un impact sur la façon dont vous restreignez l'accès aux données par différents chemins.

Accès réservé aux propriétaires de contenu

Ces règles restreignent l'accès au propriétaire authentifié du contenu uniquement. Les données ne sont lisibles et inscriptibles que par un seul utilisateur, et le chemin des données contient l'ID de l'utilisateur.

Quand cette règle fonctionne : Cette règle fonctionne bien si les données sont cloisonnées par utilisateur — si le seul utilisateur qui doit accéder aux données est le même utilisateur qui a créé les données.

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

Pour configurer cette règle : Créez une règle qui confirme que l'utilisateur demandant l'accès en lecture ou en écriture aux données est bien l'utilisateur propriétaire de 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 mixte public et privé

Cette règle permet à quiconque de lire un ensemble de données, mais restreint la possibilité de créer ou de modifier des données sur un chemin donné au seul propriétaire de contenu authentifié.

Quand cette règle fonctionne : cette règle fonctionne bien pour les applications qui nécessitent des éléments lisibles publiquement, mais qui doivent restreindre l'accès en modification aux propriétaires de ces éléments. Par exemple, une application de chat ou un blog.

Lorsque cette règle ne fonctionne pas : comme la règle du 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 autres.

Pour configurer cette règle : créez une règle qui autorise l'accès en lecture à tous les utilisateurs (ou à tous les utilisateurs authentifiés) et confirme que l'utilisateur qui écrit les données 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 basé sur les rôles

Pour que ces règles fonctionnent, vous devez définir et attribuer des attributs aux utilisateurs dans vos données. Les règles de sécurité Firebase vérifient la demande par rapport aux données de votre base de données ou aux métadonnées de votre fichier pour confirmer ou refuser l'accès.

Quand cette règle fonctionne : si vous attribuez un rôle aux utilisateurs, cette règle facilite la limitation de l'accès en fonction de rôles ou de groupes spécifiques d'utilisateurs. Par exemple, si vous stockiez des notes, vous pourriez attribuer différents niveaux d'accès au groupe « étudiants » (lire leur contenu uniquement), au groupe « enseignants » (lire et écrire dans leur matière) et au groupe « directeurs » (lire tout le contenu).

Lorsque 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 vos fichiers pour refléter les attributs que vous utilisez dans vos règles.

Pour configurer cette règle : dans Cloud Firestore, incluez un champ dans les documents de vos utilisateurs que vous pouvez lire, puis structurez votre règle pour lire ce champ et accorder l'accès sous condition. Dans Realtime Database, créez un chemin de données qui définit les utilisateurs de votre application et leur accorde un rôle dans un nœud enfant.

Vous pouvez également configurer des revendications personnalisées dans l'authentification , puis récupérer ces informations à partir de la variable auth.token dans n'importe quelle règle de sécurité Firebase.

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 mettre en œuvre ces règles, configurez des revendications personnalisées dans l'authentification Firebase, puis exploitez les revendications de 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 mettre en œuvre ces règles, configurez la multilocation dans Google Cloud Identity Platform (GCIP), puis exploitez le locataire dans vos règles. Les exemples suivants autorisent les écritures d'un utilisateur dans 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;
  }
}