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 des règles flexible signifie que vous pouvez créer des règles qui correspondent à tout, de toutes les écritures à l'ensemble 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 basiques que vous pourriez vouloir 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 pouvez en savoir plus sur la langue qu'ils sont écrits et leur comportement .

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

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 restreindre l' accès à vos données (mode verrouillé) ou autoriser l' accès à quiconque (mode Test). Dans Nuage Firestore et Base de données en temps réel, les règles par défaut pour le mode Locked refuser l' accès à tous les utilisateurs. Dans Cloud Storage, seuls les utilisateurs authentifiés peuvent accéder aux buckets de stockage.

Cloud Firestore

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

Base de données en temps réel

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

Stockage en ligne

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. Rappelez - vous aussi que si vous déployez votre application, il est accessible au public - même si vous ne l' avez pas lancé il.

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 pour les utilisateurs malveillants. Définir des règles séparément de la logique du produit présente un certain nombre d'avantages : les clients ne sont pas responsables de l'application de la sécurité, les implémentations boguées ne compromettront pas vos données et, surtout, 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.

Cloud Firestore

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

Base de données en temps réel

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

Stockage en ligne

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 vous préparez à déployer votre application, assurez-vous que vos données sont protégées et que l'accès est correctement accordé à vos utilisateurs. Effet de levier d' authentification pour configurer l'accès par utilisateur et lire directement à partir de votre base de données pour configurer l'accès sous forme de 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 manière dont vous restreignez l'accès aux données à différents chemins.

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

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

Lorsque cette règle fonctionne: Cette règle fonctionne bien si les données sont cloisonnés par l' utilisateur - si le seul utilisateur qui a besoin d'accéder aux données est le même utilisateur qui a créé les données.

Lorsque cette règle ne fonctionne pas: Ce ruleset ne fonctionne pas lorsque plusieurs utilisateurs ont besoin d'écrire ou de lire les mêmes données - les utilisateurs écrasent les données ou être incapable d'accéder aux données qu'ils ont créés.

Pour mettre en place cette règle: créer une règle qui confirme l'utilisateur demandant l' accès à lire ou à des données d'écriture est l'utilisateur qui possède ces données.

Cloud Firestore

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

Base de données en temps réel

{
  "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"
      }
    }
  }
}

Stockage en ligne

// 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 limite la possibilité de créer ou de modifier des données sur un chemin donné au propriétaire de contenu authentifié uniquement.

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

Lorsque cette règle ne fonctionne pas: Comme le propriétaire du contenu seule règle, ce ruleset ne fonctionne pas lorsque plusieurs utilisateurs doivent modifier les mêmes données. Les utilisateurs finiront par écraser les données des autres.

Pour mettre en place cette règle: créer une règle qui permet un accès en lecture pour tous les utilisateurs (ou tous les utilisateurs authentifiés), et confirme les données d'écriture de l' utilisateur est le propriétaire.

Cloud Firestore

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

Base de données en temps réel

{
// 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"
      }
    }
  }
}

Stockage en ligne

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 comparent la demande aux données de votre base de données ou aux métadonnées de votre fichier pour confirmer ou refuser l'accès.

Lorsque cette règle fonctionne: Si vous assignant un rôle aux utilisateurs, cette règle rend facile d'accès limite en fonction des rôles ou des groupes d'utilisateurs spécifiques. Par exemple, si vous stockiez des notes, vous pourriez affecter 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 « principaux » (lire tout le contenu).

Lorsque cette règle ne fonctionne pas: en temps réel et la base de données Cloud Storage, vos règles ne peuvent pas tirer parti de la get() méthode que les règles peuvent incorporer FireStore - Cloud. Par conséquent, vous devez structurer votre base de données ou vos métadonnées de fichier pour refléter les attributs que vous utilisez dans vos règles.

Pour mettre en place cette règle: dans les nuages Firestore, inclure un champ dans les documents de vos utilisateurs que vous pouvez lire, restructurez votre règle pour lire ce domaine et d' accorder un accès conditionnel. 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 les revendications personnalisées dans l' auth.token authentification , puis récupérer ces informations à partir de la auth.token variable dans toutes les règles 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.

Cloud Firestore

N'oubliez pas que chaque fois que vos règles incluent une lecture, comme les règles ci-dessous, vous êtes facturé pour une opération de lecture dans Cloud Firestore.

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

Base de données en temps réel

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

Attributs et rôles de revendication personnalisés

Pour mettre en œuvre ces règles, mettre en place les revendications personnalisées dans Firebase authentification et tirer parti des réclamations dans vos règles.

Cloud Firestore

N'oubliez pas que chaque fois que vos règles incluent une lecture, comme les règles ci-dessous, vous êtes facturé pour une opération de lecture dans Cloud Firestore.

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

Base de données en temps réel

{
  "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"
      }
    }
  }
}

Stockage en ligne

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