Join us for Firebase Summit on November 10, 2021. Tune in to learn how Firebase can help you accelerate app development, release with confidence, and scale with ease. Register

Apprenez la syntaxe de base du langage Firebase Security Rules for Cloud Storage

Les règles de sécurité Firebase pour Cloud Storage vous permettent de contrôler l'accès aux objets stockés dans les 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.

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

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

Les règles de sécurité Firebase pour Cloud Storage commencent toujours par la déclaration suivante :

service firebase.storage {
    // ...
}

Le service firebase.storage déclaration oscilloscopes les règles Cloud Storage, la prévention des conflits entre Cloud Storage Les règles de sécurité et des règles pour d' autres produits tels que le Cloud Firestore.

Règles de base en lecture/écriture

Les règles de base consistent en une match déclaration identifiant Cloud Storage, Seaux une déclaration de correspondance spécifiant un nom de fichier, et un allow l' expression des détails lors de la lecture est permis aux données spécifiées. allow des expressions préciser les méthodes d'accès (par exemple, lecture, écriture) en cause, et les conditions dans lesquelles l' accès est soit autorisé ou refusé.

Dans votre ruleset par défaut, la première match instruction utilise un {bucket} expression générique pour indiquer les règles applicables à tous les seaux dans votre projet. Nous discuterons davantage de l'idée des correspondances génériques 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 déclaration de correspondance peut pointer vers un fichier spécifique, comme match /images/profilePhoto.png de match /images/profilePhoto.png .

Faire correspondre les caractères génériques

En additiont à pointer vers un fichier unique, les règles peuvent utiliser des caractères génériques pour pointer vers un fichier avec un préfixe de chaîne donnée en son nom, y compris des barres obliques, comme en match /images/{imageId} .

Dans l'exemple ci - dessus, la déclaration de correspondance utilise le {imageId} syntaxe générique. Cela signifie que la règle s'applique à tout fichier /images/ au début de son nom, comme /images/profilePhoto.png ou /images/croppedProfilePhoto.png . Lorsque le allow les expressions dans la déclaration de correspondance sont évalués, la imageId Résout le nom du fichier d'image, tels que profilePhoto.png ou croppedProfilePhoto.png .

Une variable générique peut être référencé à partir du match pour fournir le nom de fichier ou une autorisation de chemin:

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

Données hiérarchiques

Comme nous l'avons dit précédemment, il n'y a pas de structure hiérarchique à l'intérieur d'un bucket Cloud Storage. Mais en utilisant une convention de nommage des fichiers, qui inclut souvent 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 les règles de sécurité Firebase interagissent avec ces noms de fichiers.

Tenez compte de la situation d'un ensemble de fichiers dont les noms commencent tous par les /images/ tige. Règles de sécurité Firebase appliquent uniquement au nom de fichier correspondant, de sorte que les contrôles d'accès définis sur les /images/ tige ne sont pas applicables à la /mp3s/ tige. Au lieu de cela, écrivez des règles explicites qui correspondent à différents modèles de nom de fichier :

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 match des déclarations, le chemin de la intérieure match instruction est toujours ajouté au chemin de l'extérieur match de déclaration. 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 de jokers que les chaînes de match et de retour à la fin d'un nom de fichier, un joker plusieurs segments peuvent être déclarés pour la mise en correspondance plus complexe en ajoutant =** au nom 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 des règles. Autrement dit, si une règle du fichier correspond à sévalue true , le résultat est true .

Dans les règles ci - dessus, le fichier « images / profilePhoto.png » peuvent être lus si l' condition ou other_condition évaluer true, alors que le fichier « images / utilisateurs / utilisateur: 12345 / profilePhoto.png » est uniquement sous réserve du résultat de other_condition .

Les règles de sécurité Cloud Storage ne sont pas en cascade et les règles ne sont évaluées que lorsque le chemin de la demande correspond à un chemin avec les règles spécifiées.

Version 1

Les règles de sécurité Firebase utilisent 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 comme /images/profilePics/profile.png, mais pas /images/badge.png. Utilisation /images/{imagePrefixorFilename=**} au lieu.

Les caractères génériques récursifs doivent figurer à 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 des règles de sécurité Firebase, les caractères génériques récursifs correspondent à zéro ou plusieurs éléments de chemin. Ainsi, /images/{filenamePrefixWildcard}/{imageFilename=**} correspond à des noms de fichiers et /images/profilePics/profile.png /images/badge.png.

Vous devez opt-in pour 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 pouvez avoir au plus un caractère générique récursif par déclaration de correspondance, mais dans la version 2, vous pouvez placer ce caractère générique n'importe où dans la déclaration de correspondance. Par 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 granulaires

Dans certaines situations, il est utile de décomposer read et write dans des opérations plus granulaires. Par exemple, votre application peut vouloir appliquer des conditions différentes lors de la création d'un fichier et lors de sa suppression.

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

Une write règle peut être divisée en create , update à delete 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 document read requests
      allow get: if <condition>;
      // Applies to list and listAll requests (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 nonexistent files
      allow create: if <condition>;

      // Applies to updates to file metadata
      allow update: if <condition>;

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

Chevauchement des déclarations de correspondance

Il est possible pour un nom de fichier pour correspondre à plus d'un match de déclaration. Dans le cas où plusieurs allow expressions correspondent à une demande, l'accès est autorisé si l' une des conditions est true :

service firebase.storage {
  match b/{bucket}/o {
    // Matches any filename containing string '/images/'.
    match /images/{imageId} {
      allow read, write: if false;
    }

    // Matches all filenames containing string `/images/`
    match /images/{imageId=**} {
      allow read, write: if true;
    }
  }
}

Dans l'exemple ci - dessus, toutes les lectures et écritures de fichiers avec la chaîne /images/ n'importe où dans leur nom seront autorisés parce que la deuxième règle est toujours true , même si la première règle est toujours false .

Les règles ne sont pas des filtres

Une fois que vous avez sécurisé vos données et commencé à effectuer des opérations sur les fichiers, gardez à l'esprit 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 accède uniquement aux fichiers auxquels le client actuel est autorisé à accéder.

Par exemple, prenons 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é: Cette règle rejette la demande suivante parce que le jeu de résultats peut inclure des fichiers où contentType n'est pas l' image/png :

la toile
filesRef = storage.ref().child("aFilenamePrefix");

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

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

Prochaines étapes

Vous pouvez approfondir votre compréhension des règles de sécurité Firebase pour le stockage cloud :

  • Apprendre le prochain concept majeur de la langue règles, dynamiques conditions , qui laissez votre autorisation utilisateur vérifier les règles, comparer les données existantes et entrantes, valider les données entrantes et plus.

  • Passez en revue les cas d'utilisation typiques de la sécurité et les définitions Règles de sécurité Firebase cette adresse leur .

Vous pouvez explorer les cas d'utilisation des règles de sécurité Firebase spécifiques à Cloud Storage :