Supabaseで1.6万件のDB露出！Vibe Coding狂騒曲とRLS崩壊の危機

• 事実：セキュリティ企業UpGuardの調査で、Supabase上の約16,000件のDBが氏名やパスワード等の個人情報を公開状態にしていることが発覚。
• 技術：AIツールによる「Vibe Coding」の普及に伴い、SupabaseのRow Level Security（RLS）設定ミスや認証トークンの露出が多発。
• 対策：共有責任モデルのもと、開発者はPostgREST直結のアーキテクチャ特性を再認識し、CI/CDでのRLSポリシー検証と自動テストを即座に導入すべき。

深夜のオンコールアラートが鳴り響き、本番環境のデータベースが全開放されていたと判明した瞬間のあの背筋が凍る感覚を、読者諸君も一度は経験したことがあるだろうか。今、それと同じ惨劇が、生成AI時代の寵児として持て囃されるクラウドデータベース「Supabase」のプラットフォーム上で、地球規模で発生している。

セキュリティ調査会社UpGuardが発表した衝撃的なレポートによると、Supabase上で稼働しているデータベースのうち、実に約16,000件ものプロジェクトにおいて、ユーザーの個人情報や機密データが一般のWeb上に丸見えの状態で放置されていたことが明らかになった。漏洩していたデータには、個人の氏名、住所、電話番号といった基本情報にとどまらず、ハッシュ化されていない生パスワードや認証トークン、米国のバレーパーキングサービスが管理する大量の自動車ナンバープレート、さらには成人向けストリーミングサービスにおける秘密の対話ログや、フランス在住のアフリカ各国領事館のデータまで含まれていたという。

なぜ、このような恐ろしい事態が起きてしまったのか。その背景にあるのは、近年空前の爆発的ブームを見せている「Vibe Coding（バイブコーディング）」の台頭だ。Lovableの年換算売上（ARR）が6億ドルを突破するなど、プロンプトを入力するだけでフロントエンドからバックエンドまでを一気通貫でビルドするAI開発ツールの普及速度は凄まじい。Supabase自身もその波に乗り、企業価値100億ドルというユニコーン企業へと急成長を遂げた。しかし、AIツールに身を任せて「ノリと雰囲気」でアプリをデプロイする非エンジニアや経験浅い開発者が激増した結果、データベースのセキュリティ設定という、最も泥臭く本質的な工程が完全に置き去りにされたのだ。我々エンジニアがこれまで積み上げてきた「境界防御」や「最小権限の原則」といった設計思想は、AIが吐き出す綺麗なコードの影で跡形もなく消し去られていたのである。

Supabaseのコアアーキテクチャに触れたことがあるエンジニアなら、同社がPostgreSQLの上に構築された極めて洗練されたBaaS（Backend as a Service）であることを知っているだろう。特に、PostgRESTを活用してフロントエンドからJavaScript SDK経由で直接データベースを操作できる直感性は、従来のREST APIやGraphQLサーバーを自分で構築する手間を劇的に削減してくれた。しかし、この「フロントエンドから直接DBを叩ける」という極上の開発体験（DX）こそが、今回の大規模流出における最大の技術的罠（Trap）となっている。

Supabaseにおいてデータアクセスを保護する唯一無二の砦は、PostgreSQLが持つ「RLS（Row Level Security：行レベルセキュリティ）」だ。SupabaseのCISOであるBil Harmer氏は「当社のプロジェクトは初期状態で安全（Secure by default）であり、責任は共有責任モデル（Shared Responsibility Model）に基づいている」と反論している。しかし、現実の開発現場において何が起きているかを直視すべきだ。AI生成ツールは「動くコード」を最優先で生成するため、テーブル作成時に ALTER TABLE items ENABLE ROW LEVEL SECURITY; を発行し忘れたり、あるいはアクセスエラー（401 Unauthorizedや403 Forbidden）を解決するために、AIが提案するがまま CREATE POLICY "Enable read access for all users" ON "public"."users" FOR SELECT USING (true); といった無差別全開ポリシーを適用してしまうケースが後を絶たない。

競合であるFirebaseでは、セキュリティルールを設定しないと読み書きが拒否される強い制約や明確な警告UIが存在するが、Supabaseの直感的なダッシュボードと高速なデプロイパイプラインは、不慣れな開発者に「設定が完了している」という無根拠な全能感を与えてしまう。以下の表は、今回の漏洩で確認されたデータ種別と、技術的発生要因を整理したものだ。

我々プロのシニアエンジニアが抱く懸念は深刻だ。プラットフォーム側が「ツールとデフォルト設定は提供した、あとはユーザーの責任だ」と言い切る姿勢は、規約上は正論であっても、現実のWeb空間に巨大なセキュリティホールを撒き散らす結果となっている。コードを書かない「バイブコーダー」たちに責任を押し付けるだけで、このスパゲッティ化されたセキュリティ危機を解決できるはずがない。

では、AIがコードを書き、誰もが数分でWebアプリを立ち上げられるこの狂乱の時代において、我々エンジニアはどのようなスタンスをとり、現場を守っていくべきなのだろうか。AIの手を借りて開発速度を10倍にすること自体を否定するのは愚かだ。しかし、安全性の担保されていない爆速開発は、単に「バグと脆弱性を10倍の速度で生産している」だけに過ぎない。

まず、明日から実務で導入すべき即効性のある処方箋を提示したい。第1に、CI/CDパイプラインにおける「RLSの完全自動チェック」の義務付けだ。Supabase CLIや pgTAP などのテストツールをGitHub Actionsに組み込み、すべてのテーブルでRLSが有効化されているか、かつ USING (true) のような危険なポリシーが本番マイグレーションに含まれていないかを静的解析によって自動で弾く仕組みを構築しなければならない。第2に、service_role キーの厳格な隠蔽だ。フロントエンドの .env に誤って管理者権限キー（Service Role Key）が紛れ込んでいないか、gitleaks などのシークレットスキャナーをローカルフックおよびリポジトリレベルで常時監視させること。そして第3に、Supabaseのダッシュボード上で定期的に「Linter」を実行し、セキュリティ警告をゼロに保つプロセスを運用レベルで定着させることである。

だが、問題の本質はより深い場所にある。プログラミングの文法を知らない人々がAIを使ってプロダクションコードを生み出す世界において、「設計の責任」は一体どこへ帰属するのか？ AIツールベンダーは「生成されたコードの安全性をどこまで保証すべきか」、そしてクラウドインフラ側は「愚かな設定ミスを未然に防ぐガードレールをどこまで強制すべきか」。

我々エンジニアは今、単に「コードを書く作業者」から、「システム全体の安全性を監視し、AIが犯した致命的な過ちを水際で食い止める最後の砦（ゲートキーパー）」へと役割を再定義することを迫られている。「動いたからヨシ！」でリリースされた無数のアプリが、ユーザーのプライバシーを切り売りしているこの惨状を指をくわえて見ているわけにはいかない。君のチームのSupabaseプロジェクトのRLSは、今この瞬間も本当に閉じられているだろうか？