// 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 Webhook、Stripe Webhook、Supabase Webhook はすべてペイロードに署名します。署名を検証しないハンドラは、URL を推測した任意の攻撃者にとってデータベース書き込みプリミティブです。レスポンス形状で検出されます — 署名なしのリクエストが 200 を得るなら、検証はスキップされています。
FixVibe アンブレラ BaaS スキャンの仕組み
FixVibe の BaaS フェーズは 3 つのステージで実行され、それぞれが別個の検出を生成します:
- <strong>Stage 1 — provider fingerprinting.</strong> The scanner crawls the deployed app, parses every JavaScript chunk, and identifies which BaaS providers the app uses. Each provider has a distinctive runtime signature: Supabase uses <code>*.supabase.co</code>; Firebase uses <code>firebase.initializeApp({ projectId: ... })</code>; Clerk uses <code>pk_*</code> keys with a known prefix; Auth0 uses <code>clientId</code> and <code>domain</code>. The scanner records which providers are present and extracts the project identifiers.
- ステージ 2 — プロバイダ固有プローブ。 検出された各プロバイダに対して、スキャナはプロバイダ固有のチェックを実行します:
baas.supabase-rlsは PostgREST を探り、baas.firebase-rulesは Firestore + RTDB + Storage を探り、baas.clerk-auth0はバンドルされたキーのプレフィックスを検証し、バンドルシークレットチェックはサービスティア資格情報が漏洩していないことを検証します。各プローブは独立して実行されます — Supabase の検出は Firebase スキャンをブロックしません。 - ステージ 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 (Snyk / Semgrep) |
|---|---|---|---|
| BaaS カバレッジ | Supabase、Firebase、Clerk、Auth0、Appwrite のネイティブチェック | 汎用 Web クロール、プロバイダ固有プローブなし | リポジトリのみの静的解析、本番検証なし |
| セットアップ時間 | URL → 実行 → 60 秒で結果 | 数時間: スパイダー、認証、スコープを構成 | 1 日: リポジトリ CI に統合 |
| 何を証明するか | HTTP レベルの証拠を伴う本番ランタイム露出 | Web アプリ脆弱性 (XSS、SQLi)、BaaS は手動構成経由 | デプロイされるかもしれない、されないかもしれないコードパターン |
| JavaScript バンドル検査 | JWT をデコードし、シークレットプレフィックスを照合し、チャンクを巡回 | 限定的 — 文字列ベース grep のみ | あり、ただしリポジトリ側のみ、デプロイ側なし |
| 継続的スキャン | 月次 / デプロイ時に API + MCP 経由 | 手動、スケジュールは自分で構成 | コミットごと (コードには良いがランタイムには盲目) |
| ソロ / 小チームの価格 | 無料プラン、有料は $19/月から | Burp Pro $499/年、ZAP は無料だが偽陽性が多い | Snyk 無料 / Semgrep 無料、有料層は $25/開発者から |
誠実なスコープ: このスキャナが置き換えないもの
BaaS 対応 DAST スキャナは焦点を絞ったツールであり、完全なセキュリティプログラムではありません。次のことはしません:
- SAST や SCA を置き換える。 静的解析は、DAST スキャナにはできない依存関係 CVE (Snyk、Semgrep) とコードレベル脆弱性 (SonarQube) を発見します。両方を実行してください。
- 手動ペネトレーションテストを置き換える。 人間のペンテスターは、スキャナにはできないビジネスロジック欠陥、認可エッジケース、連鎖した脆弱性を発見します。大きなローンチやコンプライアンス監査の前にペンテスターを雇ってください。
- git 履歴内のシークレットについてコードやリポジトリを監査する。 バンドルシークレットチェックは現在デプロイされているものをカバーし、過去にコミットされたものをカバーしません。リポジトリ衛生には
git-secretsやgitleaksを使用してください。 - 非 BaaS バックエンドサービスをカバーする。 アプリがカスタムバックエンド (Express、Rails、Django、FastAPI) を使用する場合、FixVibe は HTTP 表面をスキャンしますが、その背後のデータベースやインフラを探りません。それは汎用 DAST + SAST の領域です。
よくある質問
アンブレラスキャンはアプリが 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 + 正しいルールが多層防御のパターンです。
スキャナは修正を検証できますか?
はい — 修正を適用したら再実行します。チェック ID (例: baas.supabase-rls) は実行間で安定しているため、検出を差分できます: 実行 1 で open だった検出が実行 2 で不在であれば、修正が着地した証拠です。
次のステップ
本番 URL に対して無料の FixVibe スキャンを実行してください — BaaS フェーズチェックは無料プランを含むすべてのプランで提供されます。プロバイダ固有の深堀りについては、このセクションの個別記事が各プロバイダを詳細にカバーしています: Supabase RLS、Supabase サービスキー露出、Supabase ストレージ、Firebase ルール、Firebase if-true、Clerk、Auth0。