Corriger les règles non sécurisées
Utilisez ce guide pour comprendre les failles courantes des configurations des règles de sécurité Firestore, 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 Firestore n'est pas correctement sécurisée, vous pouvez résoudre les failles en modifiant et en testant vos règles de sécurité Firestore.
Pour consulter vos règles de sécurité, accédez à l'onglet Règles dans la console Firebase.
Comprendre vos règles de sécurité Firestore
Les règles de sécurité Firestore protègent vos données contre les utilisateurs malveillants. Par défaut, les règles de toute instance 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 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 règles de sécurité Cloud Firestore que vous avez configurées par défaut ou que vous avez initialement développées avec 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
Lors de la configuration de Firestore, vous avez peut-être défini des règles autorisant le libre accès lors du 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.
| Scénario non recommandé : accès en lecture et en écriture pour tous les utilisateurs. |
// 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; } } }
| 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 pour remédier à ce scénario non sécurisé consiste à appliquer une sécurité basée sur l'utilisateur à l'aide de Firebase Authentication. En savoir plus sur l'authentification des utilisateurs à l'aide de règles. |
Propriétaire de contenu uniquement
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; } } }
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 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, les règles de sécurité Firestore vérifient qu'un utilisateur est connecté, mais ne limitent 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.
| Scénario non recommandé : tout utilisateur connecté dispose d'un accès en lecture et en écriture à l'ensemble de votre base de données. |
service cloud.firestore { match /databases/{database}/documents { match /some_collection/{document} { 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 l'ajout de conditions de sécurité et l'accès basé sur des rôles. |
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 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. } } }
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
}
}
}
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 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.
Obtenez plus d'informations sur les règles de sécurité Firestore en consultant la section Premiers pas avec les règles de sécurité Firestore.
Vérifier vos règles de sécurité Firestore
Pour vérifier le comportement de votre application et vérifier la configuration de vos règles de sécurité Firestore, utilisez l'émulateur Firestore. Utilisez l'émulateur Firestore pour exécuter et automatiser des tests unitaires dans un environnement local avant de déployer des modifications.
Pour tester rapidement vos nouvelles règles de sécurité Firestore dans la console Firebase, utilisez l'espace de test dédié aux règles.
- 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).
- 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)
- 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.