Corriger les règles non sécurisées

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

Si vous recevez une alerte indiquant que votre base de données Cloud Firestore n'est pas correctement sécurisée, vous pouvez résoudre les failles en modifiant et en testant votre Cloud Firestore Security Rules.

Pour consulter vos règles de sécurité, accédez à l'onglet Règles dans la console Firebase.

Comprendre votre Cloud Firestore Security Rules

Cloud Firestore Security Rules protège vos données contre les utilisateurs malveillants. Par défaut, les règles de toute instance Cloud Firestore créée dans la console Firebase refusent l'accès à tous les utilisateurs. Pour développer votre application et accéder à votre base de données, vous devez modifier ces règles et envisager d'accorder un accès global à tous les utilisateurs d'un environnement de développement. Prenez le temps de configurer correctement vos règles et de sécuriser vos données avant de déployer votre application dans un environnement de production.

Lorsque vous développez votre application et testez différentes configurations pour vos règles, utilisez l'émulateur Cloud Firestore pour exécuter votre application dans un environnement de développement local.

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

Les Cloud Firestore Security Rules que vous avez configurées par défaut ou que vous avez initialement développées avec Cloud Firestore 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

Lorsque vous avez configuré Cloud Firestore, vous avez peut-être défini des règles pour autoriser le libre accès 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.

// Allow read/write access to all users under any conditions
// Warning: **NEVER** use this rule set in production; it allows
// anyone to overwrite your entire database.

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

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow only authenticated content owners access
    match /some_collection/{document} {
      // Allow reads and deletion if the current user owns the existing document
      allow read, delete: if request.auth.uid == resource.data.author_uid;
      // 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;

    }
  }
}
  

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

Accès pour tout utilisateur authentifié

Parfois, Cloud Firestore Security Rules vérifie qu'un utilisateur est connecté, mais ne limite pas pour autant l'accès en fonction de cette authentification. Si l'une de vos règles inclut auth != null, confirmez que vous souhaitez qu'un utilisateur connecté ait accès aux données.

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

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 request.auth != null && get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Reader"
     allow write: if request.auth != null && 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.
    }
  }
}

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

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

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 :

// Deny read/write access to all users under any conditions
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      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 en tant que serveur backend 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.

Pour en savoir plus sur Cloud Firestore Security Rules et son fonctionnement, consultez la section Premiers pas avec Cloud Firestore Security Rules.

Vérifiez votre Cloud Firestore Security Rules

Pour vérifier le comportement de votre application et vérifier vos configurations Cloud Firestore Security Rules, utilisez l'émulateur Cloud Firestore. Utilisez l'émulateur Cloud Firestore pour exécuter et automatiser des tests unitaires dans un environnement local avant de déployer des modifications.

Pour tester rapidement votre Cloud Firestore Security Rules mis à jour dans la console Firebase, utilisez l'outil Rules Playground.

1. Pour ouvrir l'espace de test dédié aux règles, cliquez sur Rules playground (Espace de test dédié aux règles) dans l'onglet Rules (Règles).
2. Dans les paramètres Rules playground (Espace de test dédié aux règles), sélectionnez les options de votre test, y compris :
   • Lectures ou écritures de test
   • Emplacement spécifique (Location) dans votre base de données, sous forme de chemin
   • Type d'authentification : utilisateur non authentifié, utilisateur anonyme authentifié ou ID utilisateur spécifique
   • Données du document auxquelles vos règles font référence (par exemple, si vos règles exigent la présence d'un champ spécifique avant d'autoriser une écriture)
3. Cliquez sur Run (Exécuter) et recherchez les résultats dans la bannière située au-dessus de la fenêtre des règles.