Firebase Security Rules vous permet de contrôler l'accès à vos données stockées. La syntaxe des règles flexibles vous permet de créer des règles qui correspondent à toutes sortes d'éléments : toutes les écritures de l'intégralité de la base de données, ou bien les opérations sur un document spécifique.
Ce guide décrit certains des cas d'utilisation les plus basiques que vous pouvez implémenter 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 la section Gérer et déployer 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 doit restreindre 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.
Cloud Firestore
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write: if false;
}
}
}
Realtime Database
{
"rules": {
".read": false,
".write": false
}
}
Cloud Storage
service firebase.storage {
match /b/{bucket}/o {
match /{allPaths=**} {
allow read, write: if request.auth != null;
}
}
}
Règles de l'environnement de développement
Lorsque vous travaillez sur votre application, vous pouvez souhaiter un accès relativement ouvert ou illimité à vos données. Assurez-vous simplement de mettre à jour votre Rules 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 Firebase Security Rules sont la seule protection bloquant l'accès des utilisateurs malveillants. Définir des règles séparément 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 entier.
Tous les utilisateurs authentifiés
Bien que nous ne recommandions pas de laisser vos données accessibles à tous les utilisateurs connectés, il peut être utile de définir l'accès à tous les utilisateurs authentifiés lorsque vous développez votre application.
Cloud Firestore
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write: if request.auth != null;
}
}
}
Realtime Database
{
"rules": {
".read": "auth.uid !== null",
".write": "auth.uid !== null"
}
}
Cloud Storage
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. Utilisez Authentication 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.
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. Les données ne sont lisibles et accessibles en écriture que par un seul utilisateur, et le chemin d'accès aux 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, c'est-à-dire si le seul utilisateur qui a besoin d'accéder aux données est celui qui les a créées.
Cas où cette règle ne fonctionne pas:ce jeu de règles ne fonctionne pas lorsque plusieurs utilisateurs doivent écrire ou lire les mêmes données. Les utilisateurs écrasent les données ou ne peuvent pas y accéder.
Pour configurer cette règle:créez une règle qui confirme que l'utilisateur qui demande l'accès pour lire ou écrire des données est le propriétaire 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
}
}
}
Realtime Database
{
"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"
}
}
}
}
Cloud Storage
// 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 à n'importe qui de lire un ensemble de données, mais limite la possibilité de créer ou de modifier des données à un chemin donné au propriétaire de contenu authentifié uniquement.
Quand cette règle fonctionne:cette règle fonctionne bien pour les applications qui nécessitent des éléments lisibles publiquement, mais qui doivent limiter l'accès en modification aux propriétaires de ces éléments. (par exemple, une application de chat ou un blog).
Cas où cette règle ne fonctionne pas:comme la règle "Propriétaire du contenu uniquement", ce jeu 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 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 public reads
allow read: if true
// Allow creation if the current user owns the new document
allow create: if request.auth.uid == request.resource.data.author_uid;
// Allow updates by the owner, and prevent change of ownership
allow update: if request.auth.uid == request.resource.data.author_uid
&& request.auth.uid == resource.data.author_uid;
// Allow deletion if the current user owns the existing document
allow delete: if request.auth.uid == resource.data.author_uid;
}
}
}
Realtime Database
{
// 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"
}
}
}
}
Cloud Storage
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 des attributs et sur des 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 vérifie la requête par rapport aux données des métadonnées de votre base de données ou de votre fichier pour confirmer ou refuser l'accès.
Quand cette règle s'applique:si vous attribuez un rôle à des utilisateurs, cette règle vous permet de limiter facilement l'accès en fonction des rôles ou de groupes d'utilisateurs spécifiques. Par exemple, si vous stockez des notes, vous pouvez attribuer différents niveaux d'accès au groupe "Élèves" (lecture uniquement), au groupe "Enseignants" (lecture et écriture dans leur matière) et au groupe "Directeurs" (lecture de tous les contenus).
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 les documents de vos utilisateurs que vous pouvez lire, puis structurez votre règle pour lire ce champ et accorder l'accès de manière conditionnelle. 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 récupérer ces informations à partir de 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.
Cloud Firestore
N'oubliez pas que chaque fois que vos règles incluent une lecture, comme les règles ci-dessous, une opération de lecture vous est facturée 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"
}
}
}
Realtime Database
{
"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 implémenter ces règles, configurez des revendications personnalisées dans Firebase Authentication, puis exploitez-les dans vos règles.
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";
}
}
}
Realtime Database
{
"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"
}
}
}
}
Cloud Storage
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 la multi-location 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.
Cloud Firestore
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;
}
}
Realtime Database
{
"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
}
}
}
}
Cloud Storage
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;
}
}