Google は、黒人コミュニティのための人種的公平の促進に取り組んでいます。詳細をご覧ください。
このページは Cloud Translation API によって翻訳されました。
Switch to English

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

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

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

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

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

service firebase.storage {
    // ...
}

service firebase.storage宣言は、ルールをCloud Storageにスコープし、 service firebase.storageセキュリティルールとCloudFirestoreなどの他の製品のルールとの競合を防ぎます。

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

基本的なルールは、から構成され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ステートメントは、 match /images/profilePhoto.pngように、特定のファイルを指すことができます。

ワイルドカードを一致させる

単一のファイルを指すことに加えて、Rulesはワイルドカードを使用して、 match /images/{imageId}ように、名前に指定された文字列プレフィックスが付いた任意のファイルを指すことができます。

上記の例では、matchステートメントは{imageId}ワイルドカード構文を使用しています。これは、 /images/ /images/profilePhoto.png/images/croppedProfilePhoto.pngなど、名前の先頭に/images/付いているすべてのファイルにルールが適用されることを意味します。 matchステートメントのallow式が評価されると、 imageId変数はprofilePhoto.pngcroppedProfilePhoto.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 、結果はtrue

上記のルールでは、ファイル「images / profilePhoto.png」は、 conditionまたはother_conditionいずれかがtrueと評価された場合に読み取ることができますが、ファイル「images / users / user:12345 /profilePhoto.png」はother_conditionの結果のみの対象となりother_condition

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

バージョン1

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

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

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

バージョン2

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

rules_version = '2';追加して、バージョン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>;
   }
  }
}

きめ細かい操作

状況によっては、 readwriteをより詳細な操作に分割すると便利です。たとえば、アプリでは、ファイルの作成時にファイルの削除とは異なる条件を適用したい場合があります。

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 writes to existing files
      allow update: if <condition>;

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

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

ファイル名が複数のmatchステートメントと一致する可能性があります。複数のallow式がリクエストに一致する場合、条件のいずれかtrueであればアクセスが許可され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;
    }
  }
}

上記の例では、最初のルールが常にfalseであっても、2番目のルールは常にtrueであるため、ファイル名の任意の場所に文字列/images/を含むファイルへのすべての読み取りと書き込みが許可され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';
    }
  }
}

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

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

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

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

次のステップ

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

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