Éviter les règles non sécurisées

Utilisez ce guide pour comprendre les failles courantes dans Firebase Security Rules d'examiner et de mieux sécuriser vos propres règles, et de tester vos modifications avant de les déployer.

Si vous recevez une alerte indiquant que vos données ne sont pas correctement sécurisées, examiner ces erreurs fréquemment commises et mettre à jour les règles vulnérables.

Accéder à votre Firebase Security Rules

Pour afficher votre Rules existante, utilisez la CLI Firebase ou la console Firebase. Veillez à modifier vos règles de manière cohérente, en utilisant la même méthode, pour éviter d'écraser par erreur les mises à jour. En cas de doute si vos règles définies localement reflètent les mises à jour les plus récentes, la classe Firebase la console affiche toujours la dernière version déployée de votre Firebase Security Rules.

Pour accéder à vos règles depuis la console Firebase, sélectionnez votre projet, puis accédez à Realtime Database, Cloud Firestore ou Stockage : Cliquez sur Règles une fois que vous êtes dans la base de données ou l'espace de stockage approprié. bucket.

Pour accéder à vos règles à partir de la CLI Firebase, accédez à de règles indiqué dans votre fichier firebase.json.

Comprendre Firebase Security Rules

Firebase Security Rules protège vos données contre les utilisateurs malveillants. Lorsque vous créez une base de données ou un bucket Cloud Storage dans la console Firebase, vous pouvez refusez l'accès à tous les utilisateurs (mode verrouillé) ou autorisez l'accès Tous les utilisateurs (mode test) Bien que vous souhaitiez peut-être une configuration plus ouverte pendant de développement, prenez le temps de configurer correctement vos règles et sécuriser vos données avant de déployer votre application.

Lorsque vous développez votre application et testez différentes configurations utilisez l'un des émulateurs Firebase locaux pour exécuter votre application. dans un environnement de développement local.

Scénarios courants utilisant des règles non sécurisées

Les Rules que vous avez configurées par défaut ou que vous avez initialement développées avec votre application doivent être vérifiées et mises à jour avant de déployer votre application. Assurez-vous de sécuriser correctement les données de vos utilisateurs en évitant les problèmes courants suivants.

Libre accès

Lors de la configuration de votre projet Firebase, vous avez peut-être défini des règles autorisant l'ouverture pendant le développement. Vous pensez peut-être que vous êtes la seule personne à utiliser votre application, mais si vous l'avez déployée, elle est disponible sur Internet. Si vous n'authentifiez pas les utilisateurs et ne configurez pas les règles de sécurité, toute personne qui devine l'ID de votre projet peut voler, modifier ou supprimer les données.

Non recommandé:accès en lecture et en écriture pour tous les utilisateurs. Cloud Firestore // Allow read/write access to all users under any conditions // Warning: **NEVER** use this ruleset in production; it allows // anyone to overwrite your entire database. service cloud.firestore { match /databases/{database}/documents { match /{document=**} { allow read, write: if true; } } } Realtime Database { // Allow read/write access to all users under any conditions // Warning: **NEVER** use this ruleset in production; it allows // anyone to overwrite your entire database. "rules": { ".read": true, ".write": true } } Cloud Storage // Anyone can read or write to the bucket, even non-users of your app. // Because it is shared with App Engine, this will also make // files uploaded via App Engine public. // Warning: This rule makes every file in your Cloud Storage bucket accessible to any user. // Apply caution before using it in production, since it means anyone // can overwrite all your files. service firebase.storage { match /b/{bucket}/o { match /{allPaths=**} { allow read, write; } } }

Solution : règles limitant l'accès en lecture et en écriture. Créez des règles adaptées à la hiérarchie de vos données. L'une des solutions courantes à cette insécurité est la sécurité basée sur l'utilisateur avec Firebase Authentication. En savoir plus sur l'authentification des utilisateurs à l'aide de règles. Cloud Firestore Propriétaire de contenu uniquement service cloud.firestore { match /databases/{database}/documents { // Allow only authenticated content owners access match /some_collection/{document} { allow read, write: if request.auth != null && request.auth.uid == request.resource.data.author_uid } } } Accès public et privé mixte 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 write: if request.auth != null && request.auth.uid == request.resource.data.author_uid } } } Realtime Database Propriétaire de contenu uniquement { "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" } } } } Accès public et privé mixte { // 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 Propriétaire de contenu uniquement // 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.uid == userId; } } } Accès public et privé mixte 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 pour tout utilisateur authentifié

Parfois, Rules vérifie qu'un utilisateur est connecté, mais ne de restreindre l'accès en fonction de cette authentification. Si l'une de vos règles inclut auth != null, confirmez que vous souhaitez que tout utilisateur connecté ait accès à données.

Non recommandé:tout utilisateur connecté a lu et en écriture à l'ensemble de votre base de données. Cloud Firestore service cloud.firestore { match /databases/{database}/documents { match /some_collection/{document} { allow read, write: if request.auth.uid != null; } } } Realtime Database { "rules": { ".read": "auth.uid !== null", ".write": "auth.uid !== null" } } Cloud Storage // Only authenticated users can read or write to the bucket service firebase.storage { match /b/{bucket}/o { match /{allPaths=**} { allow read, write: if request.auth != null; } } }

Solution : limitez l'accès à l'aide de conditions de sécurité. Lorsque vous vérifiez l'authentification, vous pouvez également utiliser l'une des propriétés d'authentification pour limiter davantage l'accès d'utilisateurs spécifiques à des ensembles de données spécifiques. En savoir plus sur les différents propriétés d'authentification. Cloud Firestore Accès basé sur des rôles service cloud.firestore { match /databases/{database}/documents { // Assign roles to all users and refine access based on user roles 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" // Note: Checking for roles in your database using `get` (as in the code // above) or `exists` carry standard charges for read operations. } } } Accès basé sur des attributs // Give each user in your database a particular attribute // and set it to true/false // Then, use that attribute to grant access to subsets of data // For example, an "admin" attribute set // to "true" grants write access to data service cloud.firestore { match /databases/{database}/documents { match /collection/{document} { allow write: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.admin == true; allow read: true; } } } Accès public et privé mixte 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 write: if request.auth.uid == request.resource.data.author_uid } } } Realtime Database Propriétaire de contenu uniquement { "rules": { "some_path": { "$uid": { // Allow only authenticated content owners access to their data ".read": "auth.uid === $uid", ".write": "auth.uid === $uid" } } } } Accès délimité par le chemin d'accès { "rules": { "some_path/$uid": { ".write": "auth.uid === $uid", // Create a "public" subpath in your dataset "public": { ".read": true // or ".read": "auth.uid !== null" }, // Create a "private" subpath in your dataset "private": { ".read": "auth.uid === $uid" } } } } Accès public et privé mixte { // 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 Accès basé sur les groupes // 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; } Propriétaire de contenu uniquement // 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.uid == userId; } } } Accès public et privé mixte 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; } } }

(Realtime Database) Règles héritées incorrectement

Cascade Realtime Database Security Rules, avec des règles plus superficielles, les chemins parent remplaçant les règles dans les nœuds enfants plus profonds. Lorsque vous écrivez une règle sur un nœud enfant, qu'il ne peut accorder que des privilèges supplémentaires. Vous ne pouvez pas affiner ni révoquer l'accès aux données à un niveau plus profond de votre base de données.

Déconseillé:Affiner les règles au niveau des chemins d'accès enfants { "rules": { "foo": { // allows read to /foo/* ".read": "data.child('baz').val() === true", "bar": { /* ignored, since read was allowed already */ ".read": false } } } }

Solution:Écrire des règles sur les chemins d'accès parents qui sont larges et accordent des privilèges plus spécifiques sur les chemins d'accès enfants Si vos besoins en termes d'accès aux données nécessitent davantage de précision, veillez à ce que vos règles soient plus précises. En savoir plus sur la Realtime Database Security Rules en cascade dans Noyau la syntaxe de Realtime Database Security Rules.

Accès fermé

Lorsque vous développez votre application, une autre méthode courante consiste à verrouiller vos données. En général, cela signifie que vous avez désactivé l'accès en lecture et en écriture pour tous les utilisateurs, comme suit :

Cloud Firestore

// Deny read/write access to all users under any conditions
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if false;
    }
  }
}

Realtime Database

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

Cloud Storage

// Access to files through Cloud Storage is completely disallowed.
// Files may still be accessible through App Engine or Google Cloud Storage APIs.

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

Les SDK Admin Firebase et Cloud Functions peuvent toujours accéder à votre base de données. Appliquez ces règles lorsque vous envisagez d'utiliser Cloud Firestore ou Realtime Database en tant que backend serveur conjointement avec le SDK Admin Firebase. Bien qu'il soit sécurisé, vous devez vérifier que les clients de votre application peuvent récupérer correctement les données.

En savoir plus sur les Cloud Firestore Security Rules et leur fonctionnement Premiers pas avec Cloud Firestore Security Rules

Tester votre Cloud Firestore Security Rules

Pour vérifier le comportement de votre application et vérifier vos configurations Cloud Firestore Security Rules, procédez comme suit : utilisez l'émulateur Firebase. Utiliser le Cloud Firestore pour exécuter et automatiser des tests unitaires dans un environnement local avant de déployer tout changement.

Pour valider rapidement Firebase Security Rules dans la console Firebase, utilisez le simulateur de règles Firebase.