// docs / baas security / umbrella scanner
BaaS 設定ミススキャナ: ユーザーよりも先に公開データパスを見つける
Backend-as-a-Service プロバイダ — Supabase、Firebase、Clerk、Auth0、Appwrite、Convex — はすべて同じ形でセキュリティに失敗します: プラットフォームが妥当なデフォルトを出荷し、開発者 (または AI コーディングツール) がショートカットに手を伸ばし、未認証攻撃者と顧客データの間に公開パスが開きます。BaaS 設定ミススキャナは、攻撃者と同じように外部からそのパスを探る唯一のツールです。本記事では、5 つの再発する設定ミスクラスをマッピングし、FixVibe アンブレラ BaaS スキャンの仕組みを説明し、4 つの主要プロバイダを比較し、BaaS 対応スキャナを汎用 DAST ツールと対比します。
なぜ BaaS 設定ミスは再発する形を持つのか
すべての BaaS プラットフォームは同じアーキテクチャに従います: マネージドバックエンドと、ブラウザからそれと通信する薄いクライアント SDK。ブラウザ向けクライアントは、バックエンドに自身を識別させるために 何らかの 資格情報 — anon キー、公開可能キー、Firebase プロジェクト ID — を必要とします。その資格情報は意図的に公開されており、アーキテクチャの安全性はプラットフォームレベルのアクセス制御 (RLS、ルール、許可リスト) が役目を果たすことに依存しています。
AI コーディングツールはこのアーキテクチャの上に構築しますが、プラットフォーム制御層を内面化しません。クライアント SDK を正しく配線し、プラットフォームのデフォルト寛容ルール (チュートリアル親和性のために存在する) を受け入れ、出荷します。再発する形は: 公開資格情報 + 寛容なデフォルトルール + 欠落したオーバーライド = データ露出。以下の 5 つの設定ミスクラスはすべてこの形のバリアントです。
5 つの再発する設定ミスクラス
これらはすべての BaaS プロバイダで現れます。完全なスキャンは使用中のすべてのプロバイダに対して 5 つすべてをカバーします:
クラス 1: ブラウザバンドル内の誤ったキー
ブラウザが公開 / anon 同等物の代わりにシークレット / 管理キー (Supabase service_role、Firebase Admin SDK プライベートキー、Clerk sk_*、Auth0 クライアントシークレット) を出荷します。ブラウザは制約のない管理クライアントになります。FixVibe のバンドルシークレットチェックがカバーします。
クラス 2: アクセス制御層が無効化または寛容
RLS がオフ、Firebase ルールが if true、Auth0 コールバックリストがワイルドカード。ブラウザ内の資格情報は正しいものですが — それを制約するはずのプラットフォームレベルの境界が役目を果たしていません。
クラス 3: 機密リソースの匿名読み取り
匿名読み取り可能な Firestore コレクション、匿名で列挙可能な Supabase ストレージバケット、匿名アクセス可能な Auth0 管理 API。スキャンは問います: 「資格情報なしで、私は何を読めるか?」
クラス 4: 本番環境のテストモード遺物
本番デプロイ内のテストキー (pk_test_*、sb_test_*)、ライブドメインから到達可能な dev モード Firebase アプリ、本番より弱い設定のテストテナント Auth0 アプリ。スキャンはランタイムキーを期待される本番プレフィックスと比較します。
クラス 5: Webhook 署名検証が欠落
Clerk webhooks, Stripe webhooks, Supabase webhooks all sign their payloads. A handler that doesn't verify the signature is a database-write primitive for any attacker who guesses the URL.
FixVibe アンブレラ BaaS スキャンの仕組み
FixVibe の BaaS フェーズは 3 つのステージで実行され、それぞれが別個の検出を生成します:
- Stage 1 — find the providers. FixVibe loads the deployed app and identifies which BaaS providers it talks to — Supabase, Firebase, Clerk, Auth0 and others — from the configuration the browser receives.
- Stage 2 — provider checks. For each provider found, FixVibe runs that provider's checks: open Supabase tables, open Firebase rules, Clerk and Auth0 key exposure, and service-tier credentials in the bundle. Each provider is checked independently — a Supabase finding doesn't block the Firebase scan.
- ステージ 3 — プロバイダ間相関。 スキャナは検出を相互参照します。漏洩した Supabase サービスロールキーと欠落した RLS の組み合わせは、どちらか一方の検出よりも深刻です — レポートはこれを表面化します。同じアプリ内の複数の ID プロバイダ (Clerk + Auth0 + カスタム認証) はレビュー用にフラグされる構造的検出です。
すべてのプローブはパッシブです: リソースごとに最大 1 回の匿名読み取り、レスポンス形状は記録されますが行内容はページングまたは保存されません。書き込みおよび変更プローブは検証済みドメイン所有権の背後でゲートされ、未検証のターゲットに対しては決して実行されません。
プロバイダごとにスキャナが何を見つけるか
各 BaaS プロバイダには異なる表面と異なるスキャン戦略があります。カバーされる内容:
- Supabase: テーブルでの RLS 欠落、匿名で列挙可能なストレージバケット、バンドル内の漏洩した
service_roleJWT またはsb_secret_*キー、匿名 OpenAPI 一覧経由で露出したスキーマ。Supabase RLS スキャナとストレージチェックリストを参照。 - Firebase: Firestore、Realtime Database、Cloud Storage 上の
if trueルール、匿名で列挙可能な Storage バケット、欠落した App Check 強制。Firebase ルールスキャナとIf-true ルール解説を参照。 - Clerk: バンドルされた
sk_*シークレットキー、本番のpk_test_*、欠落した Webhook 署名検証、ワイルドカード許可オリジン。Clerk チェックリストを参照。 - Auth0: バンドルされたクライアントシークレット、有効化された Implicit グラント、ワイルドカードコールバック / ログアウト URL、SPA での欠落 PKCE。Auth0 チェックリストを参照。
BaaS スキャナと汎用 DAST / SAST ツールの比較
BaaS 対応スキャナは他のツールがやらない特定の作業をします。比較:
| 観点 | FixVibe (BaaS 対応 DAST) | 汎用 DAST (Burp / ZAP) | SAST / SCA (スニック / セムグレップ) |
|---|---|---|---|
| BaaS カバレッジ | Supabase、Firebase、Clerk、Auth0、Appwrite のネイティブチェック | 汎用 Web クロール、プロバイダ固有プローブなし | リポジトリのみの静的解析、本番検証なし |
| セットアップ時間 | URL → run → results usually in under a minute | 数時間: スパイダー、認証、スコープを構成 | 1 日: リポジトリ CI に統合 |
| 何を証明するか | HTTP レベルの証拠を伴う本番ランタイム露出 | Web アプリ脆弱性 (XSS、SQLi)、BaaS は手動構成経由 | デプロイされるかもしれない、されないかもしれないコードパターン |
| JavaScript バンドル検査 | Every shipped chunk, with provider-aware key detection | 限定的 — 文字列ベース grep のみ | あり、ただしリポジトリ側のみ、デプロイ側なし |
| 継続的スキャン | 月次 / デプロイ時に API + MCP 経由 | 手動、スケジュールは自分で構成 | コミットごと (コードには良いがランタイムには盲目) |
| ソロ / 小チームの価格 | Free plan; paid plans for active and repo scans | Burp Suite Professional is paid (Community Edition is free); ZAP is free and open source | Snyk and Semgrep both offer free tiers; paid tiers add scale |
Where a BaaS scan fits
A BaaS-aware scan checks what your live app exposes. Pair it with FixVibe's GitHub repo scans or another code scanner for source and dependency issues, and with a manual penetration test before a major launch or compliance audit.
よくある質問
アンブレラスキャンはアプリが 2 つの BaaS プロバイダ (例: Supabase + Clerk) を使用している場合に動作しますか?
はい — プロバイダフィンガープリントとプロバイダごとのプローブは独立しています。スキャナは両方を検出し、両方のチェックスイートを実行し、プロバイダ間相関を報告します (例: RLS 欠落と並んで email をクレームとして送る Clerk 由来の Supabase JWT テンプレート)。
これはアプリに対して Burp Suite Pro を実行することとどう違いますか?
Burp は汎用 DAST ワークベンチです。Burp は箱から出してすぐには PostgREST、Firestore、Auth0 コールバックパスを理解しません — スコープを手動で構成し、拡張機能を書き、レスポンスを解釈する必要があります。FixVibe は組み込み BaaS プローブと BaaS 形状の証拠フォーマッティングを伴います。Burp は汎用 Web アプリカバレッジ (XSS、SQLi、ビジネスロジック) で勝ち、FixVibe は BaaS 固有検出で勝ちます。
App Check (Firebase) や attestation (Apple / Google) はどうですか?
App Check は機会主義的な外部スキャンがすべてのプローブで 403 を返すようにします — 悪意のあるボットには正しい結果です。アテステーションされていないクライアントからの FixVibe スキャンは同じように振る舞います。App Check を有効にしていて FixVibe が依然として検出を報告する場合、それはルールがアテステーションされたクライアントにも開いていることを意味し、それが真のリスクです。App Check + 正しいルールが多層防御のパターンです。
スキャナは修正を検証できますか?
Yes — re-run after applying the fix. Findings keep the same identity across runs, so a finding that was open in run 1 and absent in run 2 is proof the fix landed.
次のステップ
本番 URL に対して無料の FixVibe スキャンを実行してください — BaaS フェーズチェックは無料プランを含むすべてのプランで提供されます。プロバイダ固有の深堀りについては、このセクションの個別記事が各プロバイダを詳細にカバーしています: Supabase RLS、Supabase サービスキー露出、Supabase ストレージ、Firebase ルール、Firebase if-true、Clerk、Auth0。