Catch up on everthing we announced at this year's Firebase Summit. Learn more

クラウドストレージ言語のFirebaseセキュリティルールのコア構文を学ぶ

CloudStorageのFirebaseSecurity Rulesを使用すると、CloudStorageバケットに保存されているオブジェクトへのアクセスを制御できます。柔軟なルール構文を使用すると、Cloud Storageバケットへのすべての書き込みから特定のファイルへの操作まで、あらゆる操作を制御するルールを作成できます。

このガイドでは、完全なルールセットを作成するためのCloudStorageセキュリティルールの基本的な構文と構造について説明します。

サービスとデータベースの宣言

クラウドストレージのFirebaseセキュリティルールは、常に次の宣言で始まります。

service firebase.storage {
    // ...
}

service firebase.storage宣言は、このようなクラウドFirestoreなどの他の製品のためのクラウドストレージセキュリティルールとルール間の競合を防止し、クラウドストレージにルールをスコープ。

基本的な読み取り/書き込みルール

基本的なルールは、から構成されmatchクラウドストレージバケットを特定する記述、ファイル名を指定するmatchステートメント、およびallow指定されたデータを読み取る際に詳述式が許可されています。 allow式が関与アクセス方法(例えば、読み取り、書き込み)を指定して、アクセスが許可または拒否される条件

デフォルトのルールセットでは、最初のmatch文は使用しています{bucket}のルールは、プロジェクト内のすべてのバケットに適用さを示すために、ワイルドカード表現を。ワイルドカード一致のアイデアについては、次のセクションで詳しく説明します。

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

すべてのmatchステートメントはファイルを指します。一致ステートメントはのように、特定のファイルを指すことができますmatch /images/profilePhoto.png

ワイルドカードと一致する

単一のファイルを指すへadditiontにおいて、ルールは同様に、スラッシュを含め、その名前で指定された文字列の接頭辞で任意のファイルを指すようにワイルドカードを使用することができmatch /images/{imageId}

上記の例では、一致ステートメントが使用{imageId}ワイルドカード構文。この手段規則は持つ任意のファイルに適用される/images/など、その名前の先頭に、 /images/profilePhoto.pngまたは/images/croppedProfilePhoto.png 。ときにallow matchステートメントで式が評価され、 imageId変数は、次のような、画像のファイル名に解決されますprofilePhoto.pngまたはcroppedProfilePhoto.png

ワイルドカード変数が内から参照することができますmatchファイル名またはパスの承認を提供します:

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

階層データ

前に述べたように、CloudStorageバケット内には階層構造はありません。ただし、ファイル名にスラッシュが含まれることが多いファイル命名規則を使用することで、ネストされた一連のディレクトリとサブディレクトリのように見える構造を模倣できます。 Firebaseセキュリティルールがこれらのファイル名とどのように相互作用するかを理解することが重要です。

すべてはで始まるという名前のファイルのセットの状況を考える/images/幹。上で定義されたアクセス制御のでFirebaseセキュリティルールは、唯一のマッチしたファイル名に適用されます/images/には適用されません幹/mp3s/ステム。代わりに、さまざまなファイル名パターンに一致する明示的なルールを記述します。

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

ネストときmatch文を、内部のパスmatch文は常に外側のパスに追加されたmatchのステートメント。したがって、次の2つのルールセットは同等です。

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

再帰一致ワイルドカード

ファイル名の末尾に一致し、リターン文字列は、複数のセグメントのワイルドカードを追加することによって、より複雑なマッチングのために宣言することができることをワイルドカードに加え=**のように、ワイルドカード名に{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>;
  }
}

複数のルールがファイルと一致した場合、結果はORすべてのルール評価の結果。それはどのルールがファイルにevalutesに一致した場合、あるtrue 、結果はtrue

上記の規則では、ファイル「画像/ profilePhoto.pngが」どちらかあれば読み取ることができるconditionother_conditionファイル「画像/ユーザー/ユーザー:12345 / profilePhoto.pngは」ながら、真と評価された結果にのみ対象となりother_condition

Cloud Storageのセキュリティルールはカスケードされず、ルールは、リクエストパスが指定されたルールのパスと一致する場合にのみ評価されます。

バージョン1

Firebaseセキュリティルールはデフォルトでバージョン1を使用します。バージョン1では、再帰的なワイルドカードは、0個以上の要素ではなく、1つ以上のファイル名要素に一致します。したがって、 match /images/{filenamePrefixWildcard}/{imageFilename=**} /images/profilePics/profile.pngようなファイル名と一致するが、/images/badge.pngありません。使用/images/{imagePrefixorFilename=**}代わり。

再帰的なワイルドカードは、matchステートメントの最後に配置する必要があります。

より強力な機能のために、バージョン2を使用することをお勧めします。

バージョン2

Firebaseセキュリティルールのバージョン2では、再帰的なワイルドカードが0個以上のパスアイテムに一致します。したがって、 /images/{filenamePrefixWildcard}/{imageFilename=**}一致が/images/profilePics/profile.pngと/images/badge.pngをファイル名。

あなたはオプトインする必要があり、バージョン2に追加してrules_version = '2';セキュリティルールの上部:

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

一致ステートメントごとに最大で1つの再帰ワイルドカードを使用できますが、バージョン2では、このワイルドカードを一致ステートメントの任意の場所に配置できます。例えば:

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

きめ細かい操作

いくつかの状況では、ブレークダウンすると便利ですreadおよびwriteより細かい操作に。たとえば、アプリでは、ファイルの作成時にファイルの削除とは異なる条件を適用したい場合があります。

read操作はに分けることができgetlist

writeルールはに分けることができますcreateupdate 、および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>;
    }
  }
 }
}

重複する一致ステートメント

ファイル名が複数の一致することが可能ですmatch文を。複数の場合はallow条件のいずれかがある場合の式は、要求と一致し、アクセスが許可され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;
    }
  }
}

上記の例では、すべての読み取りと文字列を含むファイルへの書き込み/images/秒ルールは常にあるので、どこでも自分のファイル名に許可されるtrue最初のルールは常にあるにもかかわらず、 false

ルールはフィルターではありません

データを保護してファイル操作の実行を開始したら、セキュリティルールはフィルターではないことに注意してください。ファイル名パターンに一致する一連のファイルに対して操作を実行することはできず、CloudStorageが現在のクライアントがアクセスする権限を持っているファイルにのみアクセスすることを期待できます。

たとえば、次のセキュリティルールを考えてみましょう。

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

拒否されました:結果セットがファイル含めることができますので、このルールは、次の要求を拒絶contentTypeないimage/png

ウェブ
filesRef = storage.ref().child("aFilenamePrefix");

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

Cloud Storageセキュリティルールのルールは、潜在的な結果に対して各クエリを評価し、クライアントが読み取る権限を持たないファイルを返す可能性がある場合、リクエストを失敗させます。アクセス要求は、ルールで設定された制約に従う必要があります。

次のステップ

クラウドストレージのFirebaseセキュリティルールについての理解を深めることができます。

CloudStorageに固有のFirebaseセキュリティルールのユースケースを調べることができます。