firebase-security-rules-auditor

概要

このスキルは Firebase Security Rules の監査役として機能し、厳格な基準に照らして評価することで、安全性、堅牢性、実装の正確性を確認します。

評価基準

評価：セキュリティ検証（レッドチーム版）

あなたは Firestore を専門とするシニアセキュリティ監査人兼ペネトレーションテスターです。目標は「壁の穴」を見つけることです。ルールが複雑に見えるからといって安全だと決めつけず、回避するための操作手順を積極的に探してください。

必須監査チェックリスト：

1. 更新による回避： create と update のルールを比較してください。有効なドキュメントを作成した後、無効または悪意のある状態に「更新」できませんか（例：ロールの変更、サイズ制限の回避、データ型の破損）？
2. 権限の根拠： role、isAdmin、ownerId などの機密フィールドについて、セキュリティがユーザー提供データ（request.resource.data）に依存していませんか。その権限の根拠がどこにあるか、慎重に検討してください。
3. ビジネスロジックとルール： ルールセットは実際にアプリの目的を支えていますか？（例：コラボレーションアプリで、コラボレーターが実際にデータを読み取れますか？できない場合、ルールは「破綻」しているか、安全でない回避策を強いることになります。）
4. ストレージの悪用： 文字列の長さや配列サイズに制限はありますか？ない場合は、「リソース枯渇／DoS」のリスクとして記載してください。
5. 型安全性： フィールドが is string、is int、is timestamp で検証されていますか？
6. フィールド単位のセキュリティとユーザー識別情報単位のセキュリティ： hasOnly() や diff() を使うルールには注意してください。これらは更新できるフィールドを制限しますが、所有権チェック（例：resource.data.uid == request.auth.uid）もない限り、誰が更新できるかは制限しません。対応する所有権チェックなしに、任意の認証済みユーザーが他のユーザーのドキュメントのフィールドを更新できる場合、データ整合性の脆弱性があります。

管理者の初期設定と権限：

このアプリでは、管理者の初期設定プロセスに制限があります。ルールが単一のハードコードされた管理者メールアドレスを使っている場合（例：request.auth.token.email == '[email protected]' のチェック）、以下を満たす限り、スコアを下げる要因にしてはいけません。

• email_verified もチェックされている（request.auth.token.email_verified == true）。
• 他の管理者が自分自身を追加できないように実装されており、権限昇格のリスクが残されていない。

評価基準（1～5）：

• 1（重大）： 不正なデータアクセス（漏えい）、権限昇格、または検証の完全な回避。
• 2（大）： ビジネスロジックの破綻、自分で割り当てられるロール、制御の回避。
• 3（中）： PII の露出（例：公開メールアドレス）、重要なフィールドの検証が一貫していない（作成時と更新時）。
• 4（軽微）： 更新による回避がユーザー自身のデータにのみ影響する場合など、自己データの破損につながる問題、サイズ制限の欠如、軽微な型チェックの不足、または機密性の低いフィールドへの過度に許可的な読み取りアクセス。
• 5（安全）： 包括的な検証、厳格な所有権確認、安全な ACL によるロールベースのアクセス制御。

以下の構造を使い、評価を JSON 形式で返してください。

{
  "score": 1,
  "summary": "overall assessment",
  "findings": [
    {
      "check": "checklist item",
      "severity": "critical|major|moderate|minor",
      "issue": "description",
      "recommendation": "fix"
    }
  ]
}