firebase-security-rules-auditor
Firestore のセキュリティルールを、攻撃側の視点で読み直させる。5 段階で採点まで
npx skills add firebase/agent-skills/firebase-security-rules-auditor入れる前にこのスキルがすること・注意点・SKILL.md の原文を確かめてください。解析は安全性の判定ではありません。
- インストール
- 141,767
- 実用度
- 26
- GitHub star
- 505
- 最終更新
- 2026/11/5
頼み方の例
そのままコピーして使えますfirebase-security-rules-auditorを使って、添付のfirestore.rulesを監査してください。とくにcreateとupdateの差から権限を書き換えられないか、roleのようなフィールドをユーザー側のデータから読んでいないかを見てください。指摘ごとに、実際に破る操作の順序を書いてください。
対象のファイルや状況は、ご自身の作業に合わせて置き換えてください。
このスキルがすること
SKILL.md の記述から機械的に抽出- 外部通信・シェル実行・ファイル操作の記述は見つかりませんでした
これは安全性の判定ではありません。 SKILL.md にそう書かれているという事実だけを並べています。実際に問題があるかは使い方と文脈で決まるため、当サイトでは断定しません。導入前に SKILL.md の原文を確認してください。
SKILL.md の規模
コードブロックの言語: json
いつ使うか
Firebase のセキュリティルールを書いたあと、公開する前に通してください。
このスキルは「ルールを読んで解説する」のではなく、破る方法を探す側の視点で読み直します。本文の言葉では「複雑に見えるからといって安全だと決めつけず、迂回できる操作の並びを能動的に探せ」。
確認する観点は 6 つ
確認する観点は 6 つに決まっています。
- 更新による迂回正当な形で作成してから、
updateで不正な状態に書き換えられないか - 権限の出どころ
roleやisAdminを、利用者が送ってきたデータから読んでいないか - 業務要件との整合厳しすぎて本来の機能が動かず、危険な回避策を招いていないか
- 保存の乱用文字列の長さや配列の大きさに上限があるか（無ければ枯渇のリスク）
- 型の安全性
is stringis intis timestampで検査しているか - 所有者の確認
hasOnly()やdiff()だけで満足していないか
1 つ目と 6 つ目が、とくに実務で刺さります。
1 つ目: 作成は厳しく、更新は緩い
作成時は厳しく検査しているのに、更新時の検査が緩い、というのはよくある書き方です。攻撃側から見れば、正しい形で 1 度作ってから書き換えるだけで通ります。
6 つ目: hasOnly() は「誰が」を縛らない
6 つ目も間違えやすいところです。hasOnly() はどのフィールドを更新できるかは縛りますが、誰が更新できるかは縛りません。
所有者の確認（resource.data.uid == request.auth.uid）を併記していないと、認証さえ通っていれば他人の文書を書き換えられます。
結果は 1〜5 の段階と JSON
結果は 1〜5 の段階と JSON で返ります。1 が「重大（情報漏えい、権限昇格、検査の全面的な迂回）」、5 が「堅牢」です。
使わないほうがいいとき
Firebase のセキュリティルール以外
Firebase のセキュリティルール以外には使えません。本文が明示的に除外しています。
- Firebase CLI の操作（ログイン、デプロイ）
- Firebase Authentication そのものの設定
- Crashlytics、Remote Config
- データベースへの問い合わせ
監査の代わりにはなりません
これはルールのテキストを読む道具です。アプリ側の実装、Cloud Functions、管理用の経路は見ていません。
ルールをまだ書いていない段階
ルールをまだ書いていない段階では効きません。読む対象がありません。
注意点
解析で見つかったこと
SKILL.md の解析では、外部通信・シェル実行・ファイル操作の記述は見つかっていません。コードブロックの言語は JSON のみ、同梱の実行可能なスクリプトもありません。Firebase プロジェクトに接続する手順も本文にはありません。
ルールのテキストを読んで採点する、それだけのスキルです。セキュリティ関連のスキルとしては、渡すものが少なくて済む部類です。
渡すのはアクセス制御の設計そのもの
管理者をメールアドレスで直書きしているときの例外
管理者の扱いについて、このスキルは現実的な例外を持っています。管理者の判定をメールアドレス 1 つの直書きで行っている場合、次の 2 つを満たしていれば減点しない、と明記されています。
request.auth.token.email_verified == trueも確認している- 他の管理者を自分で追加できる作りになっていない
杓子定規に減点しない設計で、小規模なアプリには現実的です。とはいえ、利用者が増えたら見直す前提の書き方であることは意識してください。
インストール数と分類の大きさ
インストール数は約 13.6 万件（2026-10-21 の上流集計）で、上位のスキルには及びません。セキュリティの分類自体が小さいためでもあります（セキュリティ・監査）。
順位が低いことと、あなたの用途に合わないことは別です。Firebase を使っているなら、順位に関係なく候補に入ります。
インストール数の推移
日次で記録9月18日 〜 11月7日（49日分）
インストール数と 1 日あたりの増加は Skillselion が に集計した値です。上流の更新は数日おきなので、前日比ではありません。GitHub star と最終更新は に GitHub から取得しました。
よくある質問
Cloud Storage のルールにも使えますか
使えます。本文で Firestore と Cloud Storage の両方が対象だと明記されています。観点はほぼ共通で、とくにサイズの上限（保存の乱用）は Storage のほうが重要になります。
出てきた JSON はそのまま CI に流せますか
形式は決まっていますが、このスキル自体に CI の仕組みはありません。エージェントの実行と、結果の受け取りを自分で組む必要があります。また、生成される内容は毎回同じとは限らないため、段階の数値だけで機械的に合否を決める使い方は勧めません。
指摘された内容は必ず直すべきですか
段階 1 と 2 は直してください。情報漏えい、権限昇格、業務ロジックの破綻に当たります。3 と 4 は文脈で判断してください。たとえば「公開前提の掲示板でメールアドレスが読める」のような指摘は、設計としてそうしている場合もあります。指摘の理由と、実際に破れる操作の順序を確認してから判断してください。