TOP > Google Cloud Platform (GCP) > 【実用】Firebase Firestore Database, Realtime Database, Storageのルール設定

【実用】Firebase Firestore Database, Realtime Database, Storageのルール設定

約 6 分
【実用】Firebase Firestore Database, Realtime Database, Storageのルール設定

Firebase

スマホアプリやWebシステムなどで mBaaS として Firebase を利用している方は多いと思います。
特に Firestore Database, Realtime Database, Storage などは非常に便利であるため、これらを目的に好んで Firebase を利用したりもするでしょう。
これらを利用するとき、開発のためにテストモードで開始する方が多いです。しかしテストモードはセキュリティが低く、場合によっては誰でも操作できてしまいます。開発中であったとしても Firebase Auth と連携し、最低限のセキュリティは保っておいた方がいいでしょう。
今回は、Firebase Auth の UID を利用した最低限のルールを紹介します。

Firestore Database

Firestore の場合、本番環境モードで開始すると、全ての階層において誰も読み書きできないルールになっています。

本番環境モードで開始する

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if false;
    }
  }
}

テストモードで開始する

一方テストモードで開始すると、データベースを作ってから1ヶ月間は、全ての階層において誰でも読み書きできるルールになっています。この状態での利用は好ましくないですね。開発がズルズルと伸びると、この期間も同じくズルズルと伸ばしてしまいがちです。直ぐにでもルールを見直しましょう。
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if
          request.time < timestamp.date(2021, 11, 25);
    }
  }
}

Firebase Auth と連携

アクセスするユーザの Firebase Auth の UID は、 request.auth.uid で取得できます。以下の例では、 /users の配下に自身の UID の階層を持ち、そこにアクセスするときは読み書き可能なルールになっています。
自分自身しか読み書きできないので、大きな問題になることはないでしょう。 
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read, write: if request.auth != null  && userId == request.auth.uid;
    }
  }
}
この例では、 read と write に対してルールを設定していますが、厳密には
  • read … get, list
  • write … create, update, delete
      • と細かく設定することができ、詳細については割愛しますが write にはそれぞれ個別にルールを割り振った方がいいでしょう。

      Realtime Database

      Realtime Database は、Firestore と設定が異なります。

      ロックモードで開始

      Firestore でいうところの本番環境モードになります。 read, write 共に false としているので、誰も読み書きすることができません。
      {
  "rules": {
    ".read": false,
    ".write": false
  }
}

      テストモードで開始する

      一方テストモードでは、データベース作成から1ヶ月間は誰でも読み書きできるルールです。
      {
  "rules": {
    ".read": "now < 1636124400000",  // 2021-11-25
    ".write": "now < 1636124400000",  // 2021-11-25
  }
}

      Firebase Auth と連携

      アクセスするユーザの Firebase Auth の UID は、 auth.uid で取得できます。こちらも Firestore と同じように /users の配下に自身の UID の階層を持ち、そこにアクセスするときは読み書き可能なルールとして設定してみました。
      {
  "rules": {
    "users": {
      "$uid": {
        ".read": "$uid === auth.uid",
        ".write": "$uid === auth.uid",
      }
    }
  }
}

      Storage

      Storage にもルールが存在します。設定方法は、 Firestore と同じです。ただし、本番環境モードやテストモードなどは用意されておらず最初のルールが決まっています。
      その内容は Firebase Auth を利用していれば誰でも読み書きできるものですが、他のユーザのコンテンツを除き見れるのは気持ち悪いです。明確なルールを用意した方がいいでしょう。

      最初(テストモードなし)

      rules_version = '2';
service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write: if request.auth != null;
    }
  }
}

      Firebase Auth と連携

      Firestore と同様にアクセスするユーザの Firebase Auth の UID は、 request.auth.uid で取得できます。 /users の配下に自身の UID の階層を持ち、その配下のファイルにアクセスするときは読み書き可能なルールになっています。
      rules_version = '2';
service firebase.storage {
  match /b/{bucket}/o {
    match /users/{uid}/{file_name} {
      allow read, write: if request.auth.uid == uid;
    }
  }
}

      まとめ

      一度ルールを設定すれば安心ですが、先延ばしにしてしまうことが多々あります。上記はコピーアンドペーストで利用できるので、データベースやストレージを作成したら真っ先にこれらを適用して最低限のルールを作ってしまいましょう。

      関連記事

» エンジニア登録はこちら