Storage セキュリティ ルールを使ってみる

一般的なアプリでは、デベロッパーは多くのサーバーを構築して維持し、認証、承認、データ検証を行い、デベロッパーのビジネス ロジックを実施する必要があります。Firebase Storage を使用するアプリは Firebase Authentication と Firebase Storage セキュリティ ルールを利用して、サーバーレスな認証、承認、データ検証を行うことができます。

Firebase Storage と Storage セキュリティ ルールを使用すると、インフラストラクチャを管理したり、サーバー側の複雑な認証コードや承認コードを作成したりする必要がなくなるため、デベロッパーは優れたユーザー エクスペリエンスを構築することだけに集中できます。

概要

Firebase Storage セキュリティ ルールは、Firebase Storage に格納されているファイルの読み取りアクセス権や書き込みアクセス権を持つユーザーを決定します。また、ファイルの構成方法やファイルに含まれるメタデータの種類も決定します。基本のルールは allow ルールです。これは、オプションで指定されている条件を満たす場合に read 操作と write 操作を許可します。次に、ルールの例をいくつか示します。

// Rules can optionally specify a condition
allow write: if <condition>;

ルール match のファイルパスは Firebase Storage 参照を表しています。ルールは、match を使用して 1 つ以上のファイルパスと照合できます。match を使用した複数のルールが特定の request 内のファイルパスと一致することもあります。

// Rules match specific paths
match /images/profilePhoto.png {
  allow write: if <condition>;
}

match /images/croppedProfilePhoto.png {
  allow write: if <other_condition>;
}

ルール評価のコンテキストも request オブジェクトと resource オブジェクトを使って示されます。これらのオブジェクトは、認証コンテキスト(request.auth)と既存のオブジェクト サイズ(resource.size)などの情報を提供します。

// Rules can specify conditions that consider the request context
match /images/profilePhoto.png {
  allow write: if request.auth != null && request.resource.size < 5 * 1024 * 1024;
}

Storage セキュリティ ルールについて詳しくは、ファイルの保護のセクションをご覧ください。

サンプルルール

Storage セキュリティ ルールでは、まず service(この例では firebase.storage)と、ルールの評価対象となる Firebase Storage バケット(match /b/<your-firebase-storage-bucket>/o 経由)を指定する必要があります。デフォルトのルールには Firebase Authentication が必要ですが、ここでは別のアクセス制御を持つ他の一般的なルールの例を示します。

デフォルト

// Only authenticated users can read or write to the bucket
service firebase.storage {
  match /b/<your-firebase-storage-bucket>/o {
    match /{allPaths=**} {
      allow read, write: if request.auth != null;
    }
  }
}

公開

// Anyone can read or write to the bucket, even non-users of your app.
// Because it is shared with Google App Engine, this will also make
// files uploaded via GAE public.
service firebase.storage {
  match /b/<your-firebase-storage-bucket>/o {
    match /{allPaths=**} {
      allow read, write;
    }
  }
}

ユーザー

// Grants a user access to a node matching their user ID
service firebase.storage {
  match /b/<your-firebase-storage-bucket>/o {
    // Files look like: "user/<UID>/path/to/file.txt"
    match /user/{userId}/{allPaths=**} {
      allow read, write: if request.auth.uid == userId;
    }
  }
}

非公開

// Access to files through Firebase Storage is completely disallowed.
// Files may still be accessible through Google App Engine or GCS APIs.
service firebase.storage {
  match /b/<your-firebase-storage-bucket>/o {
    match /{allPaths=**} {
      allow read, write: if false;
    }
  }
}

開発時には、デフォルトの代わりに公開ルールを使用して、ファイルを公開して読み取りと書き込みができるように設定することができます。こうすると、Firebase Authentication を設定せずに使い始めることができるので、プロトタイプの場合は非常に便利です。しかし、Firebase Storage はデフォルトの Google App Engine アプリとバケットを共有するため、このルールによって Google App Engine アプリが使用するすべてのデータも公開されることになります。

ユーザールールでは、認証済みのユーザーにそれぞれ個人用ファイル ストレージを提供することができます。プライベート ルールを使用してファイルを完全にロックすることもできますが、その場合はユーザーが Firebase Storage でファイルの読み取りも書き込みもできなくなることにご注意ください。ただしこの場合でも、Google App Engine アプリか GCS API を使用してファイルにアクセスするユーザーはアクセスが可能です。

アプリケーションを公開する前に、ルールを評価して、アプリケーションに必要な最大レベルのセキュリティを確保できていることをご確認ください。

ルールの編集

Firebase Storage では、Firebase console の [ストレージ] セクションにある [ルール] タブから、Storage セキュリティ ルールを簡単に編集することができます。[ルール] タブでは、現在のルールをすばやく簡単に表示して編集することができます。ルールは [公開] ボタンをクリックするか、ファイルに保存(ctrl/cmd + s)することによってデプロイします。ルールは即座に Firebase Storage サーバーにアップロードされますが、有効になるまでに最長 5 分程度かかることがあります。

ファイルベースのセキュリティの仕組みについて詳しくは、ファイルの保護のセクションをご覧ください。ユーザーベースのセキュリティについては、ユーザー セキュリティのセクションをご覧ください。

フィードバックを送信...