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

Utilisez ce guide pour comprendre les vulnérabilités courantes dans les configurations des règles de sécurité Firebase, 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 vos données ne sont pas correctement sécurisées, examinez ces erreurs courantes et mettez à jour toutes les règles vulnérables.

Accédez à vos règles de sécurité Firebase

Pour afficher vos règles existantes, utilisez la CLI Firebase ou la console Firebase. Assurez-vous de modifier vos règles en utilisant la même méthode, de manière cohérente, pour éviter d'écraser par erreur les mises à jour. Si vous n'êtes pas sûr que vos règles définies localement reflètent les mises à jour les plus récentes, la console Firebase affiche toujours la version la plus récemment déployée de vos règles de sécurité Firebase.

Pour accéder à vos règles depuis la console Firebase , sélectionnez votre projet, puis accédez à Realtime Database , Cloud Firestore ou Storage . Cliquez sur Règles une fois que vous êtes dans la bonne base de données ou le bon compartiment de stockage.

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

Comprendre les règles de sécurité de Firebase

Les règles de sécurité Firebase protègent vos données des utilisateurs malveillants. Lorsque vous créez une instance de base de données ou un bucket Cloud Storage dans la console Firebase, vous pouvez choisir de refuser l'accès à tous les utilisateurs ( Mode verrouillé ) ou d'accorder l'accès à tous les utilisateurs ( Mode Test ). Même si vous souhaitez peut-être une configuration plus ouverte pendant le développement, assurez-vous de prendre le temps de configurer correctement vos règles et de sécuriser vos données avant de déployer votre application.

Pendant que vous développez votre application et testez différentes configurations pour vos règles, utilisez l'un des émulateurs Firebase locaux pour exécuter votre application dans un environnement de développement local.

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

Les règles que vous avez peut-être configurées par défaut ou lorsque vous avez initialement travaillé sur le développement de votre application doivent être examinées et mises à jour avant de déployer votre application. Assurez-vous de bien sécuriser les données de vos utilisateurs en évitant les pièges courants suivants.

Accès ouvert

Lors de la configuration de votre projet Firebase, vous avez peut-être défini vos 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 de règles de sécurité, toute personne devinant 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;
    }
  }
}

Base de données en temps réel

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

Stockage en ligne

// 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 qui restreignent l'accès en lecture et en écriture.

Créez des règles adaptées à votre hiérarchie de données. L'une des solutions courantes à cette insécurité est la sécurité basée sur l'utilisateur avec l'authentification Firebase. En savoir plus sur l'authentification des utilisateurs avec des règles .

Cloud Firestore

Base de données en temps réel

Stockage en ligne

Accès pour tout utilisateur authentifié

Parfois, les règles vérifient qu'un utilisateur est connecté, mais ne restreignent pas davantage 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 aux données.

Non recommandé : tout utilisateur connecté dispose d'un accès en lecture et en écriture à l'intégralité 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;
    }
  }
}

Base de données en temps réel

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

Stockage en ligne

// 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 : restreindre l'accès à l'aide de conditions de sécurité.

Lorsque vous vérifiez l'authentification, vous souhaiterez peut-être également utiliser l'une des propriétés d'authentification pour restreindre davantage l'accès à des utilisateurs spécifiques pour des ensembles de données spécifiques. En savoir plus sur les différentes propriétés d'authentification .

Cloud Firestore

Base de données en temps réel

Stockage en ligne

(Base de données en temps réel) Règles mal héritées

Cascade de règles de sécurité de base de données en temps réel, avec des règles sur des chemins parents plus superficiels remplaçant les règles sur des nœuds enfants plus profonds. Lorsque vous écrivez une règle sur un nœud enfant, n'oubliez pas qu'elle ne peut accorder que des privilèges supplémentaires. Vous ne pouvez pas affiner ou révoquer l'accès aux données à un chemin plus profond dans votre base de données.

Non recommandé : affiner les règles au niveau des chemins enfants
{
  "rules": {
     "foo": {
        // allows read to /foo/*
        ".read": "data.child('baz').val() === true",
        "bar": {
          /* ignored, since read was allowed already */
          ".read": false
        }
     }
  }
}
Solution : Écrivez des règles larges sur les chemins parents et accordez des privilèges plus spécifiques aux chemins enfants. Si vos besoins d'accès aux données nécessitent plus de granularité, gardez vos règles granulaires. Apprenez-en davantage sur la mise en cascade des règles de sécurité de base de données en temps réel dans Syntaxe de base des règles de sécurité de base de données en temps réel .

Accès fermé

Pendant que vous développez votre application, une autre approche courante consiste à verrouiller vos données. En règle générale, cela signifie que vous avez fermé l'accès en lecture et en écriture à 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;
    }
  }
}

Base de données en temps réel

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

Stockage en ligne

// 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 Firebase Admin et Cloud Functions peuvent toujours accéder à votre base de données. Utilisez ces règles lorsque vous avez l'intention d'utiliser Cloud Firestore ou Realtime Database comme backend serveur uniquement en conjonction avec le SDK Firebase Admin. Bien qu'elle soit sécurisée, vous devez vérifier que les clients de votre application peuvent récupérer correctement les données.

Apprenez-en davantage sur les règles de sécurité Cloud Firestore et leur fonctionnement dans la section Premiers pas avec les règles de sécurité Cloud Firestore .

Testez vos règles de sécurité Cloud Firestore

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

Pour valider rapidement les règles de sécurité Firebase dans la console Firebase, utilisez le Firebase Rules Simulator .