Découvrez la syntaxe de base des règles de sécurité Firebase pour le langage Cloud Storage

Firebase Security Rules pour Cloud Storage vous permet de contrôler l'accès aux objets stockés dans des buckets Cloud Storage. La syntaxe flexible des règles vous permet de créer des règles pour contrôler n'importe quelle opération, de toutes les écritures dans votre bucket Cloud Storage aux opérations sur un fichier spécifique.

Pour obtenir l'assistance IA, copiez le prompt ci-dessous dans votre agent de codage IA (comme Gemini dans Android Studio, Antigravity, Claude Code, Codex et Cursor). Vous pouvez personnaliser la requête et l'affiner avec votre agent. Pour obtenir des informations détaillées sur l'installation, consultez Compétences d'agent Firebase.

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.

Ce guide décrit la syntaxe et la structure de base de Cloud Storage Security Rules pour créer des ensembles de règles complets.

Déclaration de service et de base de données

Les fichiers Firebase Security Rules pour Cloud Storage commencent toujours par la déclaration suivante :

service firebase.storage {
    // ...
}

La déclaration service firebase.storage limite la portée des règles à Cloud Storage, ce qui évite les conflits entre Cloud Storage Security Rules et les règles d'autres produits tels que Cloud Firestore.

Règles de base pour les lectures et les écritures

Les règles de base comprennent une instruction match identifiant les buckets Cloud Storage, une instruction de correspondance spécifiant un nom de fichier et une expression allow détaillant la lecture des données spécifiées. Les expressions allow spécifient les méthodes d'accès (par exemple, lecture, écriture) impliquées et les conditions dans lesquelles l'accès est autorisé ou refusé.

Dans votre ensemble de règles par défaut, la première instruction match utilise une expression générique {bucket} pour indiquer que les règles s'appliquent à tous les buckets de votre projet. Nous aborderons plus en détail le concept de correspondance avec un caractère générique dans la section suivante.

service firebase.storage {
  // The {bucket} wildcard indicates we match files in all Cloud Storage buckets
  match /b/{bucket}/o {
    // Match filename
    match /filename {
      allow read: if <condition>;
      allow write: if <condition>;
    }
  }
}

Toutes les instructions de correspondance pointent vers des fichiers. Une instruction de correspondance peut pointer vers un fichier spécifique, comme dans match /images/profilePhoto.png.

Caractères génériques de correspondance

En plus de pointer vers un seul fichier, Security Rules peut utiliser des caractères génériques pour pointer vers n'importe quel fichier dont le nom comporte un préfixe de chaîne donné, y compris des barres obliques, comme dans match /images/{imageId}.

Dans l'exemple ci-dessus, l'instruction de correspondance utilise la syntaxe de caractère générique {imageId}. Cela signifie que la règle s'applique à tout fichier dont le nom commence par /images/, comme /images/profilePhoto.png ou /images/croppedProfilePhoto.png. Lorsque les expressions allow de l'instruction de correspondance sont évaluées, la variable imageId est résolue en nom de fichier image, tel que profilePhoto.png ou croppedProfilePhoto.png.

Une variable générique peut être référencée à partir de match pour fournir une autorisation de nom de fichier ou de chemin d'accès :

// Another way to restrict the name of a file
match /images/{imageId} {
  allow read: if imageId == "profilePhoto.png";
}

Données hiérarchisées

Comme nous l'avons déjà dit, il n'y a pas de structure hiérarchique dans un bucket Cloud Storage. Toutefois, en utilisant une convention d'attribution de noms de fichiers, souvent une convention qui inclut des barres obliques dans les noms de fichiers, nous pouvons imiter une structure qui ressemble à une série imbriquée de répertoires et de sous-répertoires. Il est important de comprendre comment Firebase Security Rules interagit avec ces noms de fichiers.

Prenons l'exemple d'un ensemble de fichiers dont les noms commencent tous par la racine /images/. Firebase Security Rules ne s'applique qu'au nom de fichier correspondant. Par conséquent, les contrôles d'accès définis sur la racine /images/ ne s'appliquent pas à la racine /mp3s/. Écrivez plutôt des règles explicites qui correspondent à différents formats de noms de fichiers :

service firebase.storage {
  match /b/{bucket}/o {
    match /images/{imageId} {
      allow read, write: if <condition>;
    }

    // Explicitly define rules for the 'mp3s' pattern
    match /mp3s/{mp3Id} {
      allow read, write: if <condition>;
    }
  }
}

Lors de l'imbrication d'instructions match, le chemin d'accès de l'instruction match interne est toujours ajouté au chemin d'accès de l'instruction match externe. Les deux ensembles de règles suivants sont donc équivalents :

service firebase.storage {
  match /b/{bucket}/o {
    match /images {
      // Exact match for "images/profilePhoto.png"
      match /profilePhoto.png {
        allow write: if <condition>;
      }
    }
  }
}
service firebase.storage {
  match /b/{bucket}/o {
    // Exact match for "images/profilePhoto.png"
    match /images/profilePhoto.png {
      allow write: if <condition>;
      }
  }
}

Caractères génériques de correspondance récursive

En plus des caractères génériques qui correspondent à des chaînes et les renvoient à la fin d'un nom de fichier, un caractère générique multisegment peut être déclaré pour une correspondance plus complexe en ajoutant =** au nom du caractère générique, comme {path=**} :

// Partial match for files that start with "images"
match /images {

  // Exact match for "images/**"
  // e.g. images/users/user:12345/profilePhoto.png is matched
  // images/profilePhoto.png is also matched!
  match /{allImages=**} {
    // This rule matches one or more path segments (**)
    // allImages is a path that contains all segments matched
    allow read: if <other_condition>;
  }
}

Si plusieurs règles correspondent à un fichier, le résultat est le OR du résultat de toutes les évaluations de règles. Autrement dit, si une règle correspondant au fichier renvoie true, le résultat est true.

Dans les règles ci-dessus, le fichier "images/profilePhoto.png" peut être lu si condition ou other_condition est évalué à "true", tandis que le fichier "images/users/user:12345/profilePhoto.png" n'est soumis qu'au résultat de other_condition.

Les règles Cloud Storage Security Rules ne sont pas appliquées en cascade et ne sont évaluées que lorsque le chemin de la requête correspond à un chemin pour lequel des règles sont spécifiées.

Version 1

Firebase Security Rules utilise la version 1 par défaut. Dans la version 1, les caractères génériques récursifs correspondent à un ou plusieurs éléments de nom de fichier, et non à zéro ou plusieurs éléments. Ainsi, match /images/{filenamePrefixWildcard}/{imageFilename=**} correspond à un nom de fichier tel que /images/profilePics/profile.png, mais pas à /images/badge.png. Utilisez plutôt /images/{imagePrefixorFilename=**}.

Les caractères génériques récursifs doivent apparaître à la fin d'une instruction de correspondance.

Nous vous recommandons d'utiliser la version 2 pour ses fonctionnalités plus puissantes.

Version 2

Dans la version 2 de Firebase Security Rules, les caractères génériques récursifs correspondent à zéro ou plusieurs éléments de chemin d'accès. Ainsi, /images/{filenamePrefixWildcard}/{imageFilename=**} correspond aux noms de fichiers /images/profilePics/profile.png et /images/badge.png.

Vous devez activer la version 2 en ajoutant rules_version = '2'; en haut de vos règles de sécurité :

rules_version = '2';
service cloud.storage {
  match /b/{bucket}/o {
   ...
 }
}

Vous ne pouvez avoir qu'un seul caractère générique récursif par instruction de correspondance, mais dans la version 2, vous pouvez placer ce caractère générique n'importe où dans l'instruction de correspondance. Exemple :

rules_version = '2';
service firebase.storage {
 match /b/{bucket}/o {
   // Matches any file in a songs "subdirectory" under the
   // top level of your Cloud Storage bucket.
   match /{prefixSegment=**}/songs/{mp3filenames} {
     allow read, write: if <condition>;
   }
  }
}

Opérations précises

Dans certains cas, il est utile de décomposer les opérations read et write en opérations plus précises. Par exemple, votre application peut vouloir appliquer des conditions différentes pour la création de fichiers et pour la suppression de fichiers.

Une opération read peut être divisée en get et list.

Une règle write peut être divisée en create, update et delete :

service firebase.storage {
  match /b/{bucket}/o {
    // A read rule can be divided into read and list rules
    match /images/{imageId} {
      // Applies to single file read requests
      allow get: if <condition>;
      // Applies to list and listAll requests (Security Rules Version 2)
      allow list: if <condition>;

    // A write rule can be divided into create, update, and delete rules
    match /images/{imageId} {
      // Applies to writes to file contents
      allow create: if <condition>;

      // Applies to updates to (pre-existing) file metadata
      allow update: if <condition>;

      // Applies to delete operations
      allow delete: if <condition>;
    }
  }
 }
}

Chevauchement d'instructions de correspondance

Un nom de fichier peut correspondre à plusieurs instructions match. Dans le cas où plusieurs expressions allow correspondent à une requête, l'accès est autorisé si au moins une des conditions est définie sur true :

service firebase.storage {
  match b/{bucket}/o {
    // Matches file names directly inside of '/images/'.
    match /images/{imageId} {
      allow read, write: if false;
    }

    // Matches file names anywhere under `/images/`
    match /images/{imageId=**} {
      allow read, write: if true;
    }
  }
}

Dans l'exemple ci-dessus, toutes les opérations de lecture et d'écriture dans les fichiers dont le nom commence par /images/ sont autorisées, car la deuxième règle est toujours true, même lorsque la première règle est false.

Les règles ne sont pas des filtres

Une fois que vous avez sécurisé vos données et que vous commencez à effectuer des opérations sur les fichiers, n'oubliez pas que les règles de sécurité ne sont pas des filtres. Vous ne pouvez pas effectuer d'opérations sur un ensemble de fichiers correspondant à un modèle de nom de fichier et vous attendre à ce que Cloud Storage n'accède qu'aux fichiers auxquels le client actuel est autorisé à accéder.

Prenons l'exemple de la règle de sécurité suivante :

service firebase.storage {
  match /b/{bucket}/o {
    // Allow the client to read files with contentType 'image/png'
    match /aFileNamePrefix/{aFileName} {
      allow read: if resource.contentType == 'image/png';
    }
  }
}

Refusée : cette règle rejette la requête suivante, car l'ensemble de résultats peut inclure des fichiers où contentType n'est pas image/png :

Web
filesRef = storage.ref().child("aFilenamePrefix");

filesRef.listAll()
    .then(function(result) {
      console.log("Success: ", result.items);
    })
});

Les règles de Cloud Storage Security Rules évaluent chaque requête par rapport à son résultat potentiel et échouent si elle peut renvoyer un fichier que le client n'est pas autorisé à lire. Les demandes d'accès doivent respecter les contraintes définies par vos règles.

Étapes suivantes

Vous pouvez approfondir vos connaissances sur Firebase Security Rules pour Cloud Storage :

  • Découvrez le prochain concept majeur du langage des règles, les conditions dynamiques, qui permettent à vos règles de vérifier l'autorisation des utilisateurs, de comparer les données existantes et entrantes, de valider les données entrantes, etc.

  • Examinez les cas d'utilisation de sécurité types et les définitions Firebase Security Rules qui les traitent.

Vous pouvez explorer les cas d'utilisation de Firebase Security Rules spécifiques à Cloud Storage :