Firebase Demo Day 2024 の日程が決定しましたユーザーに愛される最新の AI 搭載アプリを構築して実行する方法を学びましょう。詳細

Cloud Firestore セキュリティルールを構造化する

Cloud Firestore Security Rules を使用すると、データベース内のドキュメントとコレクションへのアクセスを制御できます。ルールの構文の柔軟性により、データベース全体へのすべての書き込みから特定のドキュメントに対するオペレーションまで、どのようなものにも一致するルールを作成できます。

このガイドでは、セキュリティルールの基本的な構文と構造について説明します。この構文をセキュリティルールの条件と組み合わせて、完全なルールセットを作成します。

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

Cloud Firestore Security Rules は、常に次の宣言で始まります。

service cloud.firestore {
  match /databases/{database}/documents {
    // ...
  }
}

service cloud.firestore という宣言では、ルールのスコープを Cloud Firestore とし、Cloud Firestore Security Rules と Cloud Storage などの他のプロダクトのルール間の競合を防止します。

match /databases/{database}/documents 宣言は、ルールがプロジェクト内の Cloud Firestore データベースと一致する必要があることを指定します。現在、各プロジェクトには (default) という名前のデータベースが 1 つだけあります。

基本的な読み書きのルール

基本的なルールは、ドキュメントパスを指定する match ステートメントと、指定されたデータの読み取りを許可するときに詳細を指定する allow 式で構成されます。

service cloud.firestore {
  match /databases/{database}/documents {

    // Match any document in the 'cities' collection
    match /cities/{city} {
      allow read: if <condition>;
      allow write: if <condition>;
    }
  }
}

すべての match ステートメントは、コレクションではなくドキュメントを指す必要があります。match ステートメントでは match /cities/SF のように特定のドキュメントを指すことや、match /cities/{city} のようにワイルドカードを使用して、指定されたパスのすべてのドキュメントを指すことができます。

上の例では、match ステートメントで {city} ワイルドカード構文を使用しています。つまり、このルールは、cities コレクションの、/cities/SF や /cities/NYC などのすべてのドキュメントに適用されます。match ステートメントの allow 式が評価されると、city 変数は SF や NYC などの city のドキュメント名に解決されます。

詳細なオペレーション

状況によっては、read と write をより詳細なオペレーションに分割すると便利です。たとえば、アプリで、ドキュメントの作成に対して、削除の場合とは異なる条件を適用する必要がある場合があります。または、単一のドキュメントの読み取りを許可し、大規模なクエリを拒否することが必要になる場合があります。

read ルールは get と list に分割でき、write ルールは create、update、delete に分割できます。

service cloud.firestore {
  match /databases/{database}/documents {
    // A read rule can be divided into get and list rules
    match /cities/{city} {
      // Applies to single document read requests
      allow get: if <condition>;

      // Applies to queries and collection read requests
      allow list: if <condition>;
    }

    // A write rule can be divided into create, update, and delete rules
    match /cities/{city} {
      // Applies to writes to nonexistent documents
      allow create: if <condition>;

      // Applies to writes to existing documents
      allow update: if <condition>;

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

階層データ

Cloud Firestore のデータはドキュメントのコレクションに編成されます。各ドキュメントでは、サブコレクションを使用して階層を拡張できます。セキュリティルールと階層データのインタラクションの仕組みを理解することが重要です。

cities コレクションの各ドキュメントに landmarks サブコレクションが含まれている状況を考えてみましょう。セキュリティルールは一致したパスにのみ適用されるため、cities コレクションで定義されたアクセス制御は landmarks サブコレクションには適用されません。代わりに、サブコレクションへのアクセスを制御する明示的なルールを記述します。

service cloud.firestore {
  match /databases/{database}/documents {
    match /cities/{city} {
      allow read, write: if <condition>;

        // Explicitly define rules for the 'landmarks' subcollection
        match /landmarks/{landmark} {
          allow read, write: if <condition>;
        }
    }
  }
}

match ステートメントをネストする場合、内部の match ステートメントのパスは、常に、外側の match ステートメントのパスに対する相対パスになります。したがって、次のルールセットは同等です。

service cloud.firestore {
  match /databases/{database}/documents {
    match /cities/{city} {
      match /landmarks/{landmark} {
        allow read, write: if <condition>;
      }
    }
  }
}

service cloud.firestore {
  match /databases/{database}/documents {
    match /cities/{city}/landmarks/{landmark} {
      allow read, write: if <condition>;
    }
  }
}

再帰ワイルドカード

ルールが任意の深い階層に適用されるようにするには、再帰ワイルドカード構文、{name=**} を使用します。次に例を示します。

service cloud.firestore {
  match /databases/{database}/documents {
    // Matches any document in the cities collection as well as any document
    // in a subcollection.
    match /cities/{document=**} {
      allow read, write: if <condition>;
    }
  }
}

再帰ワイルドカード構文を使用する場合、ネストが深いサブコレクションにドキュメントが置かれている場合も、ワイルドカード変数には一致するパスセグメント全体が含められます。たとえば、上に示したルールは、/cities/SF/landmarks/coit_tower に置かれたドキュメントと一致し、document 変数の値は SF/landmarks/coit_tower になります。

ただし、再帰ワイルドカードの動作は、ルールのバージョンによって異なります。

バージョン 1

セキュリティルールは、デフォルトでバージョン 1 を使用します。バージョン 1 では、再帰ワイルドカードは、1 つ以上のパスアイテムと一致します。再帰ワイルドカードは空のパスには一致しません。したがって、match /cities/{city}/{document=**} はサブコレクションのドキュメントと一致しますが、cities コレクションのものには一致しません。一方、match /cities/{document=**} は cities コレクションとサブコレクションのドキュメントの両方に一致します。

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

バージョン 2

バージョン 2 のセキュリティルールでは、再帰ワイルドカードは 0 個以上のパスアイテムに一致します。match/cities/{city}/{document=**} は、任意のサブコレクション内のドキュメントと cities コレクション内のドキュメントに一致します。

セキュリティルールの先頭に rules_version = '2'; を追加して、バージョン 2 にオプトインする必要があります。

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // Matches any document in the cities collection as well as any document
    // in a subcollection.
    match /cities/{city}/{document=**} {
      allow read, write: if <condition>;
    }
  }
}

match ステートメントごとに使用できる再帰ワイルドカードは 1 つだけですが、バージョン 2 では、このワイルドカードを match ステートメント内の任意の場所に配置できます。次に例を示します。

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // Matches any document in the songs collection group
    match /{path=**}/songs/{song} {
      allow read, write: if <condition>;
    }
  }
}

コレクショングループクエリを使用する場合は、バージョン 2 を使用する必要があります。コレクショングループクエリの保護をご覧ください。

match ステートメントの重複

1 つのドキュメントが複数の match ステートメントと一致する可能性があります。複数の allow 式がリクエストと一致する場合、いずれかの条件が true と評価されると、アクセスが許可されます。

service cloud.firestore {
  match /databases/{database}/documents {
    // Matches any document in the 'cities' collection.
    match /cities/{city} {
      allow read, write: if false;
    }

    // Matches any document in the 'cities' collection or subcollections.
    match /cities/{document=**} {
      allow read, write: if true;
    }
  }
}

上の例では、cities コレクションに対するすべての読み取りと書き込みが許可されます。これは、最初のルールが常に false になっても、2 番目のルールが常に true になるためです。

セキュリティルールの上限

セキュリティルールに関する操作では、次の制限に注意してください。

上限	詳細
リクエストあたりの `exists()`、`get()`、`getAfter()` 呼び出しの最大数	単一ドキュメントに対するリクエストとクエリリクエストの場合は 10。複数のドキュメントに対する読み取り、トランザクション、一括書き込みの場合は 20。各オペレーションには、前述の上限（10）も適用されます。たとえば、3 つの書き込みオペレーションを含めた一括書き込みリクエストを作成するとします。セキュリティルールでは、ドキュメントに対する 2 件のアクセス呼び出しを使用して、それぞれの書き込みを検証します。この場合、各書き込みオペレーションがアクセス呼び出し制限数 10 のうちの 2 つを使用するため、バッチ書き込みリクエストはアクセス呼び出し制限数 20 のうちの 6 つを使用することになります。いずれかの上限を超えると、アクセス拒否のエラーが発生します。一部のドキュメントに対するアクセス呼び出しはキャッシュされる場合があります。キャッシュされた呼び出しは上限数に計上されません。
ネストされた `match` ステートメントの深さの最大数	10
ネストされた一連の `match` ステートメント内で許可されるパスセグメント内の最大パス長	100
ネストされた一連の `match` ステートメント内で許可されるパスキャプチャ変数の最大数	20
関数呼び出しの深さの最大数	20
関数引数の最大数	7
関数あたりの `let` 変数バインディングの最大数	10
関数の再帰的な呼び出し、または循環的な呼び出しの最大数	0（許可されていません）
リクエストあたり評価される式の最大数	1,000
ルールセットの最大サイズ	ルールセットは、次の 2 つのサイズ上限に従う必要があります。 Firebase コンソールまたは CLI から `firebase deploy` を使用して公開されるルールセットテキストソースのサイズには 256 KB の上限が設定されています。 Firebase がソースを処理してバックエンドでアクティブにするときに生成される、コンパイル済みルールセットのサイズは 250 KB に制限されています。

次のステップ

カスタムセキュリティルールの条件を記述する。
セキュリティルールのリファレンスを参照する。