Firebase のセキュリティルールを、よくある26項目の間違いでチェック
Firestore のセキュリティルール、Firebase Storage のルール、Realtime Database のルールを貼り付けてください。テキストを読み取り、誰でも読み書きできるパスを示します。
結果
貼り付けたテキストの静的解析です。カスタムクレーム、App Check、データの形、デプロイされていないルールは確認できません。評価の対象は、26項目のチェックが読み取れる範囲だけです。
このチェックでは確認できないこと
チェックは貼り付けたテキストだけを読み取ります。カスタムクレーム、App Check、データの形、デプロイされていないルールは確認できないため、問題が見つからなくてもプロジェクトが安全とは限りません。
全26項目のチェック
| チェック | ID | サービス | 重大度 |
|---|---|---|---|
| 誰でも Firestore に書き込める | fs-open-write | Firestore | 緊急 |
| 誰でも Firestore から読み取れる | fs-open-read | Firestore | 中 |
| 再帰ワイルドカードの match が開いている | fs-recursive-wildcard-open | Firestore | 緊急 |
| 有効期限付きのテストモードのルール | fs-test-mode-expiry | Firestore | 緊急 |
| サインイン済みなら誰でも書き込める | fs-auth-only-write | Firestore | 高 |
| サインイン済みなら誰でも読み取れる | fs-auth-only-read | Firestore | 中 |
| email_verified なしでメールを信頼している | fs-email-unverified | Firestore | 中 |
| リクエストのデータからロールを読んでいる | fs-role-from-request | Firestore | 高 |
| 広いワイルドカードが、より厳しいルールを隠している | fs-wildcard-shadow | Firestore | 高 |
| ユーザーが自分のロールを書き込める (ヒューリスティック) | fs-self-role-write | Firestore | 高 |
| 書き込みが任意のフィールドを受け付ける (ヒューリスティック) | fs-write-no-field-guard | Firestore | 中 |
| read が get と list に分かれていない | fs-read-not-split | Firestore | 情報 |
| 明示的な既定の拒否がない | fs-no-default-deny | Firestore | 情報 |
| Firestore のルールを解析できなかった | fs-parse-error | Firestore | 情報 |
| 誰でも Storage のファイルを読み取れる | st-open-read | Storage | 中 |
| 誰でも Storage に書き込める | st-open-write | Storage | 緊急 |
| {allPaths=**} の match が開いている | st-recursive-wildcard-open | Storage | 緊急 |
| サインイン済みなら誰でも Storage に書き込める | st-auth-only-write | Storage | 高 |
| Storage のルールを解析できなかった | st-parse-error | Storage | 情報 |
| データベース全体を誰でも読み取れる | db-root-read-open | Realtime Database | 緊急 |
| データベース全体に誰でも書き込める | db-root-write-open | Realtime Database | 緊急 |
| ノードを誰でも読み取れる | db-open-read | Realtime Database | 中 |
| ノードに誰でも書き込める | db-open-write | Realtime Database | 高 |
| 子のルールが親に上書きされている | db-cascade-override | Realtime Database | 高 |
| サインイン済みのユーザーなら誰でもデータベース全体を読み書きできる | db-auth-only-root | Realtime Database | 高 |
| Realtime Database のルールを解析できなかった | db-parse-error | Realtime Database | 情報 |
よくある質問
Firebase ルールチェックでは何を見ますか？
貼り付けた Firestore、Cloud Storage、Realtime Database の Firebase セキュリティルールを読み取り、誰でも読み書きできるルール、サインイン済みのユーザーだけを条件にしているルール、クライアントからの入力を信頼しているルールなどを探します。
ルールのテキストは保存されますか？
いいえ。ルールは Cloudflare のネットワーク上でメモリ内で処理され、回答を返した後に破棄されます。テキストとともに保存や記録が行われることはありません。
どのくらい貼り付けられますか？
3つの欄を合わせて最大 48,000 文字です。ルールがそれより長い場合は、チェックしたい部分を貼り付けてください。
公開の読み取りルールが問題ない場合があるのはなぜですか？
商品カタログやブログ記事のように、公開することが目的のデータもあります。Firestore と Storage では、条件のない読み取りを「中」の問題として数え、10点を減点します。データが非公開かどうかは、チェックには分からないからです。データを意図して公開しているなら、この減点は受け入れてかまいません。Realtime Database のルートでのみ、開いた読み取りをより重大と評価します。
テストモードのルールとは何ですか？
Firestore のデータベースをテストモードで作成すると、コンソールは request.time を使って、ある日付まですべてを許可するルールを書き込みます。その日付までは誰でも読み書きでき、過ぎるとすべて拒否されてアプリが動かなくなります。公開前に、実際の条件に置き換えてください。
Realtime Database のルールはどのように継承されますか？
Realtime Database では、アクセスを許可するルールはその下のすべてに適用され、子ノードで取り消すことはできません。許可の広い親の下にある、より厳しい子のルールは決して適用されないため、チェックで指摘します。
評価は何を意味しますか？
貼り付けたテキストからチェックが読み取れる範囲だけをまとめたものです。100点から、失敗したチェックごとの減点を引いたスコアで、減点はそのチェックが見つけた最も深刻な問題で決まり、緊急の問題が1件でもあればFになります。「中」の項目は、テキストだけでは本当の問題かどうか分からないため、手作業での確認を求めるヒューリスティックの場合もあります。カスタムクレーム、App Check、データそのものは確認できないため、Aでもプロジェクトが安全だという証明にはなりません。