Utiliser des conditions dans les règles de sécurité Firebase Cloud Storage

Ce guide s'appuie sur le guide Apprendre la syntaxe de base du langage Firebase Security Rules pour vous montrer comment ajouter des conditions à votre Firebase Security Rules pour Cloud Storage.

Le composant de base de Cloud Storage Security Rules est la condition. Une condition est une expression booléenne qui détermine si une opération spécifique doit être autorisée ou refusée. Pour les règles de base, l'utilisation des littéraux true et false comme conditions fonctionne parfaitement. Toutefois, le Firebase Security Rules pour le langage Cloud Storage vous permet d'écrire des conditions plus complexes qui peuvent :

• Vérifier l'authentification des utilisateurs
• Valider les données entrantes

Help me use Firebase in my app.
1. Make sure that **Firebase agent skills** are installed and updated. For Claude Code, Codex, or Cursor agents, help me install the Firebase plugin. For other agents, run `npx skills add firebase/agent-skills`. Always try to use **Firebase agent skills** for Firebase-related tasks.
2. Help me write, validate, and deploy Firebase Security Rules to protect my app's Cloud Storage data.

Authentification

Firebase Security Rules pour Cloud Storage s'intègre à Firebase Authentication pour fournir une authentification puissante basée sur l'utilisateur à Cloud Storage. Cela permet un contrôle précis des accès en fonction des revendications d'un jeton Firebase Authentication.

Lorsqu'un utilisateur authentifié effectue une requête sur Cloud Storage, la variable request.auth est renseignée avec le uid (request.auth.uid) de l'utilisateur, ainsi qu'avec les revendications du JWT Firebase Authentication (request.auth.token).

De plus, lorsque vous utilisez l'authentification personnalisée, des revendications supplémentaires s'affichent dans le champ request.auth.token.

Lorsqu'un utilisateur non authentifié effectue une requête, la variable request.auth est définie sur null.

À partir de ces données, il existe plusieurs façons courantes d'utiliser l'authentification pour sécuriser les fichiers :

• Public : ignorer request.auth
• Authentification privée : vérifiez que request.auth n'est pas null.
• User private : vérifiez que request.auth.uid est égal à un chemin uid
• Groupe privé : vérifiez les revendications du jeton personnalisé pour qu'elles correspondent à une revendication choisie, ou lisez les métadonnées du fichier pour voir si un champ de métadonnées existe.

Public

Toute règle qui ne tient pas compte du contexte request.auth peut être considérée comme une règle public, car elle ne tient pas compte du contexte d'authentification de l'utilisateur. Ces règles peuvent être utiles pour afficher des données publiques telles que des éléments de jeu, des fichiers audio ou d'autres contenus statiques.

// Anyone to read a public image if the file is less than 100kB
// Anyone can upload a public file ending in '.txt'
match /public/{imageId} {
  allow read: if resource.size < 100 * 1024;
  allow write: if imageId.matches(".*\\.txt");
}

Privé authentifié

Dans certains cas, vous pouvez souhaiter que les données soient visibles par tous les utilisateurs authentifiés de votre application, mais pas par les utilisateurs non authentifiés. Étant donné que la variable request.auth est définie sur null pour tous les utilisateurs non authentifiés, il vous suffit de vérifier que la variable request.auth existe pour exiger l'authentification :

// Require authentication on all internal image reads
match /internal/{imageId} {
  allow read: if request.auth != null;
}

Utilisateurs (privé)

Le cas d'utilisation le plus courant pour request.auth consiste à fournir aux utilisateurs individuels des autorisations précises sur leurs fichiers, qu'il s'agisse d'importer des photos de profil ou de lire des documents privés.

Étant donné que les fichiers de Cloud Storage disposent d'un "chemin d'accès" complet, il suffit d'inclure une information unique permettant d'identifier l'utilisateur dans le préfixe du nom de fichier (comme son uid) pour qu'un fichier soit contrôlé par un utilisateur. Cette information peut être vérifiée lors de l'évaluation de la règle :

// Only a user can upload their profile picture, but anyone can view it
match /users/{userId}/profilePicture.png {
  allow read;
  allow write: if request.auth.uid == userId;
}

Groupe privé

Un autre cas d'utilisation tout aussi courant consiste à autoriser les autorisations de groupe sur un objet, par exemple en permettant à plusieurs membres d'une équipe de collaborer sur un document partagé. Plusieurs approches sont possibles :

• Générez un jeton personnalisé Firebase Authentication contenant des informations supplémentaires sur un membre du groupe (comme un ID de groupe).
• Incluez des informations sur le groupe (comme un ID de groupe ou une liste de uid autorisés) dans les métadonnées du fichier.

Une fois ces données stockées dans les métadonnées du jeton ou du fichier, elles peuvent être référencées dans une règle :

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

Demander une évaluation

Les importations, les téléchargements, les modifications de métadonnées et les suppressions sont évalués à l'aide de l'request envoyé à Cloud Storage. En plus de l'ID unique de l'utilisateur et de la charge utile Firebase Authentication dans l'objet request.auth, comme décrit ci-dessus, la variable request contient le chemin d'accès au fichier où la requête est effectuée, l'heure à laquelle la requête est reçue et la nouvelle valeur resource si la requête est une écriture.

L'objet request contient également l'ID unique de l'utilisateur et la charge utile Firebase Authentication dans l'objet request.auth, qui sera expliquée plus en détail dans la section Sécurité basée sur l'utilisateur de la documentation.

Vous trouverez ci-dessous la liste complète des propriétés de l'objet request :

Évaluation des ressources

Lorsque vous évaluez des règles, vous pouvez également évaluer les métadonnées du fichier en cours d'importation, de téléchargement, de modification ou de suppression. Cela vous permet de créer des règles complexes et puissantes qui, par exemple, n'autorisent l'importation que des fichiers avec certains types de contenu ou la suppression que des fichiers d'une certaine taille.

Firebase Security Rules pour Cloud Storage fournit les métadonnées du fichier dans l'objet resource, qui contient des paires clé/valeur des métadonnées affichées dans un objet Cloud Storage. Ces propriétés peuvent être inspectées dans les requêtes read ou write pour garantir l'intégrité des données.

Pour les requêtes write (telles que les importations, les mises à jour de métadonnées et les suppressions), en plus de l'objet resource, qui contient les métadonnées du fichier actuellement disponible au niveau du chemin d'accès de la requête, vous pouvez également utiliser l'objet request.resource, qui contient un sous-ensemble des métadonnées du fichier à écrire si l'écriture est autorisée. Vous pouvez utiliser ces deux valeurs pour garantir l'intégrité des données ou appliquer des contraintes d'application telles que le type ou la taille des fichiers.

Vous trouverez ci-dessous la liste complète des propriétés de l'objet resource :

request.resource contient tous ces éléments, à l'exception de generation, metageneration, etag, timeCreated et updated.

Améliorer avec Cloud Firestore

Vous pouvez accéder aux documents dans Cloud Firestore pour évaluer d'autres critères d'autorisation.

Grâce aux fonctions firestore.get() et firestore.exists(), vos règles de sécurité peuvent évaluer les requêtes entrantes par rapport aux documents de Cloud Firestore. Les fonctions firestore.get() et firestore.exists() attendent toutes deux des chemins d'accès aux documents entièrement spécifiés. Lorsque vous utilisez des variables pour construire des chemins d'accès pour firestore.get() et firestore.exists(), vous devez échapper explicitement les variables à l'aide de la syntaxe $(variable).

Dans l'exemple ci-dessous, nous voyons une règle qui limite l'accès en lecture aux fichiers aux utilisateurs membres de clubs spécifiques.

service firebase.storage {
  match /b/{bucket}/o {
    match /users/{club}/files/{fileId} {
      allow read: if club in
        firestore.get(/databases/(default)/documents/users/$(request.auth.id)).data.memberships
    }
  }
}

service firebase.storage {
  match /b/{bucket}/o {
    match /users/{userId}/photos/{fileId} {
      allow read: if
        firestore.exists(/databases/(default)/documents/users/$(userId)/friends/$(request.auth.id))
    }
  }
}

Une fois que vous aurez créé et enregistré votre premier Cloud Storage Security Rules utilisant ces fonctions Cloud Firestore, vous serez invité dans la console Firebase ou la CLI Firebase à activer les autorisations permettant de connecter les deux produits.

Vous pouvez désactiver la fonctionnalité en supprimant un rôle IAM, comme décrit dans Gérer et déployer Firebase Security Rules.

Valider les données

Firebase Security Rules pour Cloud Storage peut également être utilisé pour la validation des données, y compris pour valider le nom et le chemin d'accès au fichier, ainsi que les propriétés des métadonnées du fichier telles que contentType et size.

service firebase.storage {
  match /b/{bucket}/o {
    match /images/{imageId} {
      // Only allow uploads of any image file that's less than 5MB
      allow write: if request.resource.size < 5 * 1024 * 1024
                   && request.resource.contentType.matches('image/.*');
    }
  }
}

Fonctions personnalisées

À mesure que vos Firebase Security Rules se complexifient, vous pouvez encapsuler des ensembles de conditions dans des fonctions que vous pouvez réutiliser dans votre ensemble de règles. Les règles de sécurité sont compatibles avec les fonctions personnalisées. La syntaxe des fonctions personnalisées est un peu comme celle de JavaScript, mais les fonctions Firebase Security Rules sont écrites dans un langage spécifique à un domaine qui présente certaines limites importantes :

• Les fonctions ne peuvent contenir qu'une seule instruction return. Elles ne peuvent pas contenir de logique supplémentaire. Par exemple, ils ne peuvent pas exécuter de boucles ni appeler de services externes.
• Les fonctions peuvent accéder automatiquement aux fonctions et aux variables du champ d'application dans lequel elles sont définies. Par exemple, une fonction définie dans le champ d'application service firebase.storage a accès à la variable resource et, pour Cloud Firestore uniquement, aux fonctions intégrées telles que get() et exists().
• Les fonctions peuvent appeler d'autres fonctions, mais peuvent ne pas les inclure. La profondeur totale de la pile d'appel est limitée à 10.
• Dans la version rules2, les fonctions peuvent définir des variables à l'aide du mot clé let. Les fonctions peuvent comporter un nombre quelconque de liaisons let, mais doivent se terminer par une instruction return.

Une fonction est définie avec le mot clé function et accepte zéro ou plusieurs arguments. Par exemple, vous pouvez combiner les deux types de conditions utilisés dans les exemples ci-dessus en une seule fonction :

service firebase.storage {
  match /b/{bucket}/o {
    // True if the user is signed in or the requested data is 'public'
    function signedInOrPublic() {
      return request.auth.uid != null || resource.data.visibility == 'public';
    }
    match /images/{imageId} {
      allow read, write: if signedInOrPublic();
    }
    match /mp3s/{mp3Ids} {
      allow read: if signedInOrPublic();
    }
  }
}

L'utilisation de fonctions dans votre Firebase Security Rules les rend plus faciles à gérer à mesure que la complexité de vos règles augmente.

Étapes suivantes

Après cette discussion sur les conditions, vous avez une compréhension plus sophistiquée des règles et vous êtes prêt à :

Découvrez comment gérer les principaux cas d'utilisation et le workflow de développement, de test et de déploiement des règles :

• Écrivez des règles qui répondent à des scénarios courants.
• Développez vos connaissances en examinant les situations dans lesquelles vous devez identifier et éviter les règles non sécurisées.
• Testez les règles à l'aide de l'émulateur Cloud Storage et de la bibliothèque de test dédiée aux règles de sécurité.
• Examinez les méthodes disponibles pour déployer Security Rules.