16,326件のSupabaseデータベースが誰でも読める状態にある。共通点は、エージェントが作ったテーブルだ

セキュリティ企業UpGuardは9月25日、テーブルが公開インターネット上の誰からでも読める状態にあるSupabaseベースのデータベースを16,326件特定したとする調査を公開した。その半数超には、実在する人物の個人情報が含まれている。氏名、生年月日、メールアドレス、電話番号、住所。さらに一部には、平文のパスワードと認証トークンが含まれていた。

侵入は起きていない。脆弱性もパッチもCVEも存在しない。これらのデータベースはいずれも、自らの設定が指示するとおりに正確に動作している。本件が単なる情報漏えい事案と異なるのはその点だ。失敗は構造的であり、しかもそれはデフォルト設定なのである。

問題の中心にある設定

Supabaseは各プロジェクトに、ホスト型のPostgresデータベースと、その前面に置かれたRESTインターフェースを提供する。訪問者のブラウザ上で動作するクライアントサイドのコードは、Supabaseがanonキーと呼ぶ鍵を保持している。これは公開される前提のものだ。プロジェクトを識別する以上の役割はなく、Supabase自身もそのように文書化している。

この公開鍵がマスターキーとして機能しないよう歯止めをかけているのが、行レベルセキュリティ（RLS）である。特定のロールがどの行を参照できるかを決定するPostgresの機能だ。RLSが有効でポリシーが記述されていれば、匿名の訪問者はポリシーが許可した範囲しか見ることができない。RLSが無効なら、公開スキーマ内のテーブルは要求した者すべてに読み取られる。Supabase自身のドキュメントがこの点を明確に述べている。

UpGuardの主張は、この仕組みの両輪が乖離してしまったというものだ。SupabaseはTable Editorインターフェース経由で作成されたテーブルについてはRLSをデフォルトで有効にする。一方、APIを通じてプログラム的に作成されたテーブルは同じデフォルトを引き継がない。そしてプログラム的な作成こそ、コーディングエージェントがスキーマを構築する方法である。

「Supabaseはいま、安全でない設定パターンが構造的なデータ露出につながるほどの大規模普及の局面にある」と、同レポートの筆者でUpGuardのリサーチ・アンド・インサイト担当ディレクターであるGreg Pollock氏は書いている。

実際に入っているもの

UpGuardによれば、Supabaseの痕跡を持つおよそ30万のドメインを分析し、データベース全体を読み取ることなくデータ型を評価したという。名前が挙がった事例には、技術スタック以外に共通点がない。

SIMファームと領事館は同種の組織ではない。直面する敵対者も違えば、何を秘密とみなすかの感覚も違う。それでも同じ誤りを犯した。その理由についてのPollock氏の整理が、レポート中で最も鋭い一文だ。

「セキュリティ設定が業種によって変わらないのは、人間が……自分のデータベースの設定を理解していないからだ」

AIに関わる部分

これを開発者の不注意として片付けて先へ進みたくなる。だが、より有益な読み方は、いま誰が——あるいは何が——スキーマを書いているのか、という問いのほうにある。

アプリの構築を指示されたAIコーディングエージェントは、APIを通じてテーブルを作る。それが利用可能なインターフェースだからだ。そしてクライアントにanonキーを組み込む。ドキュメントがそうしろと書いているからだ。どちらの手順も、単体では正しい。実行されないのは、そもそもプロンプトに含まれていなかった手順である。すなわち、テーブルごとに「これを誰が読めるべきか」を判断する作業だ。同じアプリをダッシュボードで人間が構築していれば、安全なデフォルトが与えられていた。機械はもう一方の経路を通る。

これは、いま到来しつつある問題群全体の形を示している。セキュリティのデフォルトは、人間がコンソールの前に座り、警告を目にし、何かをクリックすることを前提に設計されてきた。エージェントはコンソールの前に座らない。安全なデフォルトがデータベースではなくUIに置かれているとき、自動化はそれを迂回する。しかも自動化が働く速度と規模で。

Supabaseの言い分

SupabaseのCISOであるBil Harmer氏はTechCrunchに対し、「当社のプロジェクトはデフォルトで安全だ」と述べ、セキュリティは同社と顧客の共同責任であると説明した。「我々はこれを正しく行うことを深く重視しており、すべての開発者がより安全に出荷できるよう改善を続けていく」と同氏は語った。

この二つは同時に成り立ちうる。Supabaseが人間向けに設計した経路においては、デフォルトは健全だ。露出が起きているのは機械がたどる経路であり、16,326件という数字は「利用者教育の問題」と呼んで済ませられるものではない。

自分がその一つを運用しているなら

確認すべきは、公開スキーマ内のすべてのテーブルでRLSが有効になっているかどうかだ。Supabaseのドキュメントは、RLSを有効にするだけでは不十分だと明言している。anonおよびauthenticatedロールに自動付与される権限も取り消す必要がある。保護されていないテーブルはプロジェクトのダッシュボードに警告として表示されるので、そのリストが出発点になる。

まず、誰も作った覚えのないテーブルから見ること。現時点の証拠に照らせば、それはおそらくエージェントが作ったものだ。

UpGuardは、調査で特定した重大な露出について所有者に通知したとしている。それらのテーブルに氏名と住所とパスワードを載せられた人々にとって、その通知だけが、彼らがこれまでに持ちえた唯一の制御手段だった。

Sources: UpGuard — Everything, Everywhere: Systemic Data Exposure in Supabase Apps · TechCrunch — Some Supabase customers are publicly exposing reams of people's data to the web · Supabase documentation — Row Level Security · Unite.AI — UpGuard Study Finds 16,326 Supabase Databases Exposing Readable Tables