Firebase セキュリティ ルールは、Firestore、Realtime Database、Cloud Storage [S1] のデータを保護するための、サーバー強制のきめ細かなメカニズムを提供します。 Firebase アプリケーションは多くの場合、これらのクラウド サービスとクライアント側から直接対話するため、これらのルールがバックエンド データ [S1] への不正アクセスを防ぐ唯一の障壁となります。
寛容なルールの影響
ルールが正しく構成されていないと、重大なデータ漏洩につながる可能性があります ([S2])。ルールが過度に寛容に設定されている場合 (たとえば、グローバル アクセスを許可するデフォルトの「テスト モード」設定を使用している場合)、プロジェクト ID を知っているすべてのユーザーがデータベース コンテンツ全体 [S2] を読み取り、変更、または削除できます。これにより、クライアント側のセキュリティ対策がすべてバイパスされ、機密のユーザー情報が失われたり、サービス全体が中断されたりする可能性があります ([S2])。
根本原因: 不十分な認証ロジック
これらの脆弱性の根本原因は通常、ユーザー ID またはリソース属性 [S3] に基づいてアクセスを制限する特定の条件を実装できていないことです。開発者は、request.auth オブジェクト [S3] を検証しない実稼働環境でデフォルト構成をアクティブのままにすることがよくあります。 request.auth を評価しないと、システムは正当な認証されたユーザーと匿名のリクエスター [S3] を区別できません。
技術的な修復
Firebase 環境を保護するには、オープン アクセスから最小権限のプリンシパル モデルに移行する必要があります。
- 認証を強制する:
request.authオブジェクトが null [S3] でないかどうかを確認して、すべての機密パスに有効なユーザー セッションが必要であることを確認します。 - アイデンティティ ベースのアクセスの実装: ユーザーの UID (
request.auth.uid) をドキュメント内のフィールドまたはドキュメント ID 自体と比較するルールを構成して、ユーザーが自分のデータ [S3] にのみアクセスできるようにします。 - 詳細なアクセス許可のスコープ: コレクションに対してグローバル ワイルドカードを使用しないでください。代わりに、各コレクションとサブコレクションに特定のルールを定義して、潜在的な攻撃対象領域 [S2] を最小限に抑えます。
- エミュレータ スイートによる検証: Firebase エミュレータ スイートを使用して、セキュリティ ルールをローカルでテストします。これにより、ライブ環境 [S2] に展開する前に、さまざまなユーザー ペルソナに対してアクセス コントロール ロジックを検証できます。
FixVibe がそれをテストする方法
FixVibe には、これが読み取り専用の BaaS スキャンとして含まれるようになりました。 baas.firebase-rules は、最新の initializeApp(...) バンドル形状を含む同じオリジン JavaScript バンドルから Firebase 構成を抽出し、認証されていない読み取り専用リクエストを使用して Realtime Database、Firestore、および Firebase ストレージをチェックします。 Firestore の場合、最初にルート コレクションのリストを試行します。リストがブロックされると、users、accounts、customers、orders、payments、messages、admin などの一般的な機密コレクション名もプローブされます。 settings。成功した匿名の読み取りまたはリストのみが報告され、顧客文書の内容の書き込み、削除、保存は行われません。