Firebase CloudStorageセキュリティルールの使用条件

このガイドは、Firebase Security Rules言語ガイドのコア構文を学習して、CloudStorageのFirebaseSecurityRulesに条件を追加する方法を示しています。

クラウドストレージセキュリティルールの主要な構成要素は条件です。条件は、特定の操作を許可するか拒否するかを決定するブール式です。基本的なルールの場合、条件としてtrueおよびfalseリテラルを使用すると、問題なく機能します。ただし、クラウドストレージ言語のFirebaseセキュリティルールを使用すると、次のようなより複雑な条件を記述できます。

• ユーザー認証を確認する
• 受信データを検証する

認証

CloudStorageのFirebaseセキュリティルールはFirebaseAuthenticationと統合され、CloudStorageに強力なユーザーベースの認証を提供します。これにより、Firebase認証トークンの申し立てに基づいたきめ細かいアクセス制御が可能になります。

認証されたユーザーがrequest.authに対してリクエストを実行すると、 request.auth変数にユーザーのuid （ request.auth.uid ）とFirebase Authentication JWTのクレーム（ request.auth.token ）が入力されます。

さらに、カスタム認証を使用する場合、追加のクレームがrequest.auth.tokenフィールドに表示されます。

認証されていないユーザーがリクエストを実行すると、 request.auth変数はnull 。

このデータを使用して、認証を使用してファイルを保護する一般的な方法がいくつかあります。

• パブリック： request.auth無視します
• 認証されたプライベート： request.authがnullでないことを確認してください
• ユーザープライベート： request.auth.uidがパスuidと等しいことを確認してください
• グループプライベート：カスタムトークンのクレームをチェックして、選択したクレームと一致させるか、ファイルメタデータを読み取って、メタデータフィールドが存在するかどうかを確認します

公衆

request.authコンテキストを考慮しないルールは、ユーザーの認証コンテキストを考慮しないため、 publicルールと見なすことができます。これらのルールは、ゲームアセット、サウンドファイル、その他の静的コンテンツなどの公開データを表示するのに役立ちます。

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

認証されたプライベート

場合によっては、アプリケーションのすべての認証済みユーザーがデータを表示できるようにしたいが、認証されていないユーザーはデータを表示できないようにすることができます。認証されていないすべてのユーザーのrequest.auth変数はnullため、認証を要求するには、 request.auth変数が存在することを確認するだけです。

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

ユーザープライベート

request.auth最も一般的な使用例は、プロフィール写真のアップロードからプライベートドキュメントの読み取りまで、個々のユーザーにファイルに対するきめ細かい権限を与えることです。

Cloud Storage内のファイルにはファイルへの完全な「パス」があるため、ユーザーがファイルを制御するために必要なのは、チェックできるファイル名プレフィックス内の一意のユーザー識別情報（ユーザーのuid ）だけです。ルールが評価されるとき：

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

グループプライベート

もう1つの同様に一般的な使用例は、複数のチームメンバーが共有ドキュメントで共同作業できるようにするなど、オブジェクトに対するグループ権限を許可することです。これを行うには、いくつかのアプローチがあります。

• グループメンバーに関する追加情報（グループIDなど）を含むFirebaseAuthenticationカスタムトークンを作成します
• ファイルメタデータにグループ情報（グループIDや承認されたuidのリストなど）を含めます

このデータがトークンまたはファイルのメタデータに保存されると、ルール内から参照できます。

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

評価をリクエストする

アップロード、ダウンロード、メタデータの変更、および削除は、CloudStorageに送信されたrequestを使用して評価されます。上記のrequest.authオブジェクト内のユーザーの一意のIDとFirebaseAuthenticationペイロードに加えて、 request変数には、リクエストが実行されているファイルパス、リクエストが受信された時刻、および新しいresource値が含まれます。リクエストは書き込みです。 HTTPヘッダーと認証状態も含まれています。

requestオブジェクトには、 request.authオブジェクトにユーザーの一意のIDとFirebase Authenticationペイロードも含まれています。これについては、ドキュメントの「ユーザーベースのセキュリティ」セクションで詳しく説明します。

requestオブジェクトのプロパティの完全なリストは、以下にあります。

リソース評価

ルールを評価するときは、アップロード、ダウンロード、変更、または削除されるファイルのメタデータを評価することもできます。これにより、特定のコンテンツタイプのファイルのみをアップロードしたり、特定のサイズを超えるファイルのみを削除したりするなど、複雑で強力なルールを作成できます。

Cloud StorageのFirebaseセキュリティルールは、 resourceオブジェクトにファイルメタデータを提供します。これには、 resourceオブジェクトに表示されるメタデータのキーと値のペアが含まれます。これらのプロパティは、データの整合性を確保するために、 readまたはwrite要求で検査できます。

writeリクエスト（アップロード、メタデータの更新、削除など）では、リクエストパスに現在存在するファイルのファイルメタデータを含むresourceオブジェクトに加えて、 request.resourceオブジェクトを使用することもできます。これには、書き込みが許可されている場合に書き込まれるファイルメタデータのサブセットが含まれています。これらの2つの値を使用して、データの整合性を確保したり、ファイルの種類やサイズなどのアプリケーションの制約を適用したりできます。

resourceオブジェクトのプロパティの完全なリストは、以下にあります。

request.resourceは、 generation 、 metageneration 、 etag 、 timeCreated 、 metageneration除いて、これらすべてが含まupdatedます。

データを検証する

Cloud StorageのFirebaseセキュリティルールは、ファイル名とパス、 contentTypeやsizeなどのファイルメタデータプロパティの検証など、データの検証にも使用できcontentType 。

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/.*');
    }
  }
}

カスタム関数

Firebaseセキュリティルールがより複雑になるにつれて、ルールセット全体で再利用できる関数で条件のセットをラップすることができます。セキュリティルールはカスタム機能をサポートします。カスタム関数の構文はJavaScriptに少し似ていますが、Firebase Security Rules関数は、いくつかの重要な制限があるドメイン固有言語で記述されています。

• 関数に含めることができるreturnステートメントは1つだけです。追加のロジックを含めることはできません。たとえば、ループを実行したり、外部サービスを呼び出したりすることはできません。
• 関数は、それらが定義されているスコープから関数と変数に自動的にアクセスできます。たとえば、 service firebase.storageスコープ内で定義された関数は、 resource変数にアクセスできます。CloudFirestoreの場合のみ、 get()やexists()などの組み込み関数がありexists() 。
• 関数は他の関数を呼び出すことができますが、再帰することはできません。コールスタックの合計深度は10に制限されています。
• バージョンrules2では、関数はletキーワードを使用して変数を定義できます。関数は任意の数のletバインディングを持つことができますが、returnステートメントで終了する必要があります。

関数はfunctionキーワードで定義され、0個以上の引数を取ります。たとえば、上記の例で使用されている2つのタイプの条件を1つの関数に結合したい場合があります。

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

Firebaseセキュリティルールで関数を使用すると、ルールの複雑さが増すにつれて、関数のメンテナンスが容易になります。

次のステップ

この条件の説明の後、ルールをより高度に理解し、次の準備が整います。

コアユースケースを処理する方法を学び、ルールを開発、テスト、および展開するためのワークフローを学びます。

• 一般的なシナリオに対応するルールを作成します。
• 安全でないルールを見つけて回避する必要がある状況を確認することにより、知識を構築します。
• ルールの展開に使用できる方法を確認します。