セキュリティ ルールの構造化

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

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

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

Cloud Firestore セキュリティ ルールは、常に、次の宣言で始まります。

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

service cloud.firestore という宣言では、ルールのスコープを Cloud Firestore とし、Cloud Firestore セキュリティ ルールと 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 変数は SFNYC などの city のドキュメント名に解決されます。

詳細なオペレーション

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

read ルールは getlist に分割でき、write ルールは createupdatedelete に分割できます。

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 になります。

再帰ワイルドカードは空のパスには一致しません。したがって、match /cities/{city}/{document=**} はサブコレクションのドキュメントと一致しますが、cities コレクションのものには一致しません。一方、match /cities/{document=**}cities コレクションとサブコレクションのドキュメントの両方に一致します。

1 つのドキュメントが複数の match ステートメントと一致する可能性があります。複数の allow 式が 1 つのリクエストと一致する場合、いずれかの条件が 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())の最大数

それぞれ 3 ですが、最大合計数は 5 です。同じドキュメントに対する複数のリクエストは、個別のリクエストとしてカウントされません。

トランザクションや一括書き込みで、単独または一連の書き込みオペレーションに関するルールを評価する場合、書き込みターゲットに対するリクエストは制限の計算対象にはなりません。

関数の呼び出しの深さの最大数 20
関数の再帰的な呼び出し、または循環的な呼び出しの最大数 0(許可されていません)
ルールセット内の式の最大数 10,000
ルールセットの最大サイズ 64 KB

次のステップ

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

ご不明な点がありましたら、Google のサポートページをご覧ください。