攻撃の流れ#

1. tl;dv に無料アカウントでサインアップする。
2. 通常のログインで得た JWT を gw.tldv.io/v1/users/firebase/token に投げると、Firebase トークンが返る¹。
3. そのトークンで Firestore（projects/lmi-store/databases/(default)）にクライアントから直接クエリできる。
4. meetings コレクションにはテナント（組織）境界のルールが無く、全アカウント・全社の会議レコードが列挙できた¹。

1レコードに含まれていた情報#

status: recording のレコードはいま生きている会議を意味する。常時およそ 1,000件がその状態でコレクション内に存在しており、コレクションをリアルタイムに監視して録画開始を検知 → conference ID を取得 → 招待されていない会議に入室、という一連の流れが成立した¹。発見者は「ボットを組めば1,000件の生会議に同時入室できた」と指摘している¹。

根本原因は「他はできていたのに、ここだけ忘れた」#

発見者の検証では、users / chats / transcripts / clips / recordings / videos / notes / teams / organizations はすべて 403 を返していた。つまり Security Rules の書き方を知らなかったわけではなく、meetings だけがルールから漏れていた¹。

これは Firebase 公式が「安全でないルール」として名指しする典型パターンのうち、「認証済みユーザーなら誰でもアクセス可」（auth != null だけのチェック）に相当する⁶。Google は「Firebase はクライアントにデータへの直接アクセスを許すため、Security Rules だけが悪意あるユーザーを止める唯一の防壁である」と明記している⁵。

実際に行われた PoC#

発見者は Firestore から取得した conference ID を使って、実際に2つの生会議へ入室している¹。

• マレーシア教育省の Google Meet。参加者157名の前でプレゼン中。tl;dv のボットも参加者リストに並んでいた。
• 米国の大手大学の学生21名のスタートアップ開発会議。画面共有でプロトタイプを見せながら「.edu メールのクライアントサイド検証を追加しよう」と話し、Supabase を画面上でセットアップしていた（発見者は「頼むから RLS を設定してくれ」と内心思った、と記している）。

この「画面の向こうで Supabase の RLS を設定し忘れそうな学生」と「Firestore のルールを1コレクションだけ忘れた tl;dv」は同じ失敗の大小違いであり、本件を象徴するエピソードになっている。

公式声明（2026-08-05）の主張#

tl;dv 側は次のように説明している²。

1. 「今年前半に、外部ペネトレーションテスト業者 Abicom の定期診断とセキュリティ研究者からの責任ある開示の双方から、会議メタデータへのアクセスに関する脆弱性が判明。修正を投入し、Abicom が正式に修正完了を検証した」
2. 「最近になって、同じ技術スタックの別の悪用経路が新たに判明。単一の脆弱性が6か月放置されたという主張には反論する——診断業者は2つの別個のベクターであると正式に証言している」
3. 「2つ目のベクターは発覚から24時間以内に修正完了」
4. 「両インシデントの共通項が Firebase であるため、Firebase をテックスタックから即時撤去する」
5. 「アクセスされ得たのはメタデータに限定（会議ID、conference ID、参加者メールとドメイン）。パスワード・録画・文字起こし・AIノート・課金情報は一切アクセスできない」
6. 「公開された文字起こし等が見えたのは、ユーザーが明示的に公開共有を ON にした会議に限られる（公開共有はデフォルト OFF のオプトイン）」
7. 「生会議への入室はごく少数の事例であり、主催者が手動で入室許可したことで成立した。この経路も修正済み」
8. 「研究者への continuous update を怠ったのは自分の責任。開示対応プロセスを改善する」

発見者の主張と公式声明の食い違い#

双方の主張が一致しているのは、Firebase まわりに穴があったことと研究者への応答を欠いたことの2点だけだ。それ以外（6か月なのか別ベクターなのか、実害の程度）は当事者間で見解が割れていて、第三者が公開情報から確定できる状態にはない。

なお、tl;dv は結果として Firebase 自体をスタックから撤去する判断をした²。これは「ルールを直す」ではなく「クライアント直アクセス型の BaaS をやめる」という、後述の教訓に直結するアーキテクチャ判断である。

事実関係#

• Base44 でバイブコーディングされた社内向けアプリ。アプリ名は “World Cup Pick’em”、社内チーム名は “Too Long; Didn’t Score”¹。
• GET /api/entities/Player がセッションクッキーなしで全プレイヤーレコードを返した（＝認証ゼロ）¹。
• 露出内容：43プレイヤー中 19名が @tldv.io の従業員、氏名・社用メールつき。開示先だった Raphael Allstadt 氏は2位（298点）で、個人の Gmail アドレスも API レスポンスに含まれていた¹。
• Prediction / Fixture エンティティも同様に開放されていた¹。
• グローバルリーダーボードの5位は “Super Duper CEO”¹。
• 公式声明の追伸：「当社チームも今年、非エンジニアの同僚が遊びでバイブコーディングした小さなワールドカップ予想アプリをサブドメインで運用していた。顧客データや本番システムとは一切接続がなく、その後アクセスを厳格化した」²。

なぜこれが最悪なのか#

1. サブドメインは隠れ蓑にならない。*.tldv.io は証明書透明性ログ（CT ログ）とサブドメイン走査で即座に列挙される。URL を知らなければ辿り着けない、というのはアクセス制御ではない。
2. 顧客データでなくても軽くはない。出たのは従業員名簿（氏名＋社用メール＋一部個人メール）であり、標的型フィッシング・ソーシャルエンジニアリングの一次資料そのもの。しかもその会社は他社の会議を全部録画している。
3. Base44 のようなプラットフォームはエンティティから REST API を自動生成する。作った本人が API を書いた自覚すらないまま /api/entities/<Entity> が公開される。バイブコーディングでは自分が何を公開したかを作者が把握していないことが常態化する。
4. 同じプラットフォームは2025年7月に認証バイパスの重大脆弱性も出している（後述）⁹。プラットフォーム側の穴とユーザー側の設定漏れが二重に乗る構造。
5. 本業の脆弱性と同じ日に露見した。社内のお遊びアプリは、インシデント時に組織のセキュリティ文化を測る証拠として使われる。技術的深刻度は低くても、レピュテーション上の破壊力は本編に匹敵する。

発見者の言葉：「何百万人もの会議を録画している会社が、社内のお遊びアプリをバイブコーディングして自社の従業員ディレクトリを漏らした。皮肉はアルデンテだ」¹

なぜ Firebase が鬼門なのか（構造的理由）#

過去の大規模事例（Firebase 設定不備）#

「公開設定」は Firebase だけの話ではない#

• Supabase の RLS：Lovable のショーケース 1,645アプリを走査したところ 170アプリ（10.3%）に重大な RLS 不備（CVE-2025-48757）が見つかった¹⁵。
• Base44 等のノーコード基盤：2025年7月、Wiz が api/apps/{app_id}/auth/register と .../auth/verify-otp が無認証で叩ける IDOR を発見。app_id は URL や manifest.json に平文で載っている非秘密値であり、これだけで他人のプライベートアプリに検証済みアカウントを作れた（SSO も迂回）^9,10。Wix は開示当日に着手し24時間以内に修正、7/29 に公開⁹。
• 横断調査：Lovable / v0 / Bolt.new / Replit / Windsurf / Tempo Labs 製の 1,072アプリを走査した Symbiotic Security の調査（2026-06）では、98% が最低1件の欠陥を持ち、16%（431サイト）が Critical だった¹⁴。

公開前チェックリスト（BaaS / バイブコーディング向け）#

A. データストアの公開設定

• Firestore / RTDB / Cloud Storage の3つすべてのルールを個別に確認した（1つでも忘れない）
• allow read, write: if true; および if request.auth != null; だけのルールが1つも残っていない⁶
• 全コレクション／全バケットを列挙し、1つずつ「誰が読めるか」を書き出した（tl;dv は9個固めて1個忘れた）
• テストモードで作った DB を本番前に必ず locked mode 相当へ書き換えた⁷
• Supabase なら全テーブルで RLS が ENABLE、かつポリシーが auth.uid() ベースでテナントを絞っている
• ルールのユニットテスト（Firebase Emulator の rules test）を CI に入れた
• 未ログイン／別テナントの実アカウントの2つで、実際に curl して 403 を確認した

B. API・エンドポイント

• 自動生成される REST/GraphQL エンドポイント（/api/entities/* 等）を全部列挙した
• 認証だけでなく認可（テナント境界・オブジェクト所有者チェック）がある（IDOR / BOLA 対策）
• Swagger / OpenAPI などのAPI ドキュメントを公開していない（Base44 事件では公開 Swagger が入口になった⁹）
• 識別子を秘密扱いしていない（app_id、conference ID、UUID は「知られない前提」で守らない）
• Firebase App Check 等のアプリ証明を有効化した（Rules と併用してこそ意味がある）⁸

C. 「公開」の意味を UI で明示する

• 「公開共有」トグルのデフォルトは OFF、ON にした時に何が誰に見えるかを明文で表示している
• リンクを知っている人だけ、という設定はリンクが漏れたら全世界であることをユーザーに伝えている（tl;dv 自身も声明でこの UX 問題を業界共通課題として認めている²）
• 公開リソースの一覧と棚卸し導線を管理者に提供している

D. サブドメイン・お遊びアプリ

• 社内向け・実験用も含め、自社ドメイン配下の全サブドメインを棚卸しした（CT ログで外部から丸見え）
• お遊びアプリでも実在の従業員情報・社用メールを入れない（ダミーで足りる）
• 本番ドメインではなく分離したドメイン／IP 制限／Basic 認証の裏に置いた
• 「もう使っていない」ものは消す（放置＝将来の記事の1セクション）

「報告を受け取れる状態」を先に作る#

報告を受けてからの初動（推奨タイムライン）#

日本の法令上の義務（個人情報保護法）#

個人データの漏えい等で「個人の権利利益を害するおそれが大きい」類型に当たる場合、個人情報保護委員会への報告と本人への通知が義務となる^16,17。

報告義務が生じる4類型¹⁷

1. 要配慮個人情報が含まれる
2. 不正利用により財産的被害が生じるおそれ
3. 不正の目的をもって行われたおそれ（＝外部攻撃・不正アクセスはここに該当しやすい）
4. 1,000人を超える漏えい等、またはそのおそれ

2段階報告^16,17

• 速報：速やかに（概ね3〜5日以内）
• 確報：発覚日から30日以内（不正の目的をもって行われたおそれがある場合は60日以内）。調査結果・影響範囲・再発防止策を含める

本件に引き付けると、「会議作成者のメールアドレス」は個人データであり、35,003ドメイン・84,312ユーザー規模は類型4を明確に超える。日本法人がこの規模の露出を認識したら、3〜5日以内の速報が必要になる水準である（tl;dv はドイツ／EU 拠点のため GDPR の72時間以内の監督機関通知が対応する義務）。

やってはいけない事後対応#

1. 既読スルー。返信しないことは「対応していない」より強い悪印象を残す（既読17:42・返信なし、が記事に載る）¹
2. 「CTO から折り返す」と言って折り返さない。窓口を人に投げて放置するのが最悪パターン¹
3. コンプライアンスバッジで守られていると思う。SOC 2 も GDPR も1コレクションのルール漏れを検出しない¹
4. メタデータだから軽微、で押し切る。conference ID のようにメタデータが認可トークン同然のケースがある
5. 発見者の記事が出てから初めて動く。8/4 記事 → 8/5 声明、という順序は「外圧で動いた」と読まれる^1,2
6. 反論だけの声明。tl;dv の声明は「2つの別ベクターだ」という反論に紙幅を割いたが、読者の記憶に残ったのはCTO 自身の謝罪部分だった²

良い事後対応の型（Base44 / Wix の例）#

Wiz が 2025-07-09 に Base44 の認証バイパスを報告してからの流れ⁹。

24時間で塞ぐ→数日で悪用有無を確認→3週間で公開、という、責任ある開示の教科書的な進行になっている。技術的な穴の深刻度（SSO 迂回・全プライベートアプリ）は tl;dv より重かったが、対応の速さゆえに事件としての傷は浅かった。

技術面#

1. BaaS は認可をクライアント側の設定ファイルに外出しするアーキテクチャだと理解する。Security Rules / RLS はアプリの認可ロジックそのものであり、コードと同じレビュー・テスト・CI の対象にする。
2. 9個できていて1個忘れる、が現実の失敗モード。個別に頑張るのではなく、全リソースを列挙して網羅性を機械的に担保する（allow の全 match をテストで踏む）。
3. 認証 ≠ 認可。無料登録できるサービスにおける auth != null は、実質的に全世界公開。
4. 識別子は防壁ではない。conference ID、app_id、サブドメイン名、共有リンク——知られなければ安全、は設計ではない。
5. メタデータの危険度を、フィールド単位で評価する。本文は守った、で安心せず、そのメタデータで何ができるか（＝入室できるか）を問う。
6. 公開設定はデフォルト OFF、ON 時は影響を明示。ユーザーの「公開」理解と実装の「公開」が食い違うのは業界共通の UX 課題²。
7. バイブコーディング成果物は、自分が何を公開したか分からない前提で扱う。自動生成されたエンドポイント・エンティティを必ず外部から列挙して確認する。

プロセス・組織面#

8. 脆弱性報告の受付は窓口ではなく当番。連絡先の記載は義務の半分でしかなく、応答する人がいて初めて機能する。
9. 書いた SLA は守る。24時間以内に応答と掲げて6か月無視した、という一文が記事の主題になった¹。
10. 止血を最優先する。恒久対策の設計を待つ間も、ルール1行で止められる出血は即座に止める。
11. 法令の時計は発覚から動く。速報3〜5日 / 確報30日（不正目的は60日）^16,17、GDPR は72時間。調査完了を待つ義務ではない。
12. 社内のお遊びアプリも資産台帳に載せる。サブドメインの棚卸しは、外部からの偵察と同じ手段（CT ログ・DNS 列挙）で自ら行う。
13. セキュリティは、他社の会話を預かる事業ほどビジネスそのもの。録画サービスにとって信頼は機能ではなく前提であり、事後対応の質がプロダクトの一部になる。
14. 最終手段としてのアーキテクチャ変更。tl;dv は Firebase 撤去を選んだ²。設定を頑張り続けるより、設定ミスが致命傷にならない構造にする方が、組織の練度が足りない場合には正しいことがある。