セキュリティ会社のUpGuardが2026年10月1日に、データベースサービスSupabaseを使うサイトの調査を公表しました。約30万のドメインから、読める表を公開しているデータベースが16,326件見つかった、という内容です。
社内ツール、予約、会員サイトを、部署や委託先がSupabaseで作っていることがあります。この記事は、UpGuardの報告とSupabaseの公式の資料を根拠に、何が分かったか、自社の確かめ方、書かれていないことを整理します。
何が分かったか(数字の表)
著者はUpGuardのGreg Pollock氏(Director of Research and Insights)です。公開は2026年10月1日です。
| 項目 |
内容 |
| 調べた範囲 |
Supabaseを使っている形跡のあるドメイン約30万。BuiltWithとChrome UX Reportのデータから集めた |
| 見つかった数 |
読める表を公開しているデータベース16,326件 |
| 調べ方 |
中身を全部読まず、表の構造(スキーマ)から、どんな種類のデータがありそうかを見積もった |
| 個人情報 |
半分超に、個人情報の形跡があった |
| パスワード・認証トークン |
より少ない割合で、形跡があった |
| クレジットカード |
ごく少数に、カードらしきデータがあった。決済サービスの利用の形跡は、より多かった |
| 地域 |
世界中で見つかった。欧州は比較的少なく、途上地域で多いとしている |
UpGuardの調査で、各項目を持つ表の割合(個人情報の形跡は55.8%)出典: UpGuard「Everything Everywhere」(引用)
図は、UpGuardが示した、項目ごとの表の割合です(表の構造を見た結果で、中身を読んだ数ではありません)。
UpGuardは、中身を確かめた5例も挙げています。サイト名はどれも伏せられています。重大なものは、UpGuardが運営者に知らせたとしています。
| 例 |
見つかったもの |
| インドのコンテンツ配信サイト |
利用者65,467人の情報と、私信10万件超 |
| フィリピンのOTP受信サービス |
利用者2,000人超と、ワンタイムパスワード入りのSMS10万件超 |
| 米国のバレーパーキング業者 |
顧客10万人超の電話番号など。従業員665件の記録 |
| アフリカのある国の領事館 |
利用者25,000人の個人情報と住所 |
| カナダの移住支援サービス |
約5,000件のうち884件に、平文のパスワード |
UpGuardは結論で、設定を誤りやすいことと利用者の多さが重なると、漏えいが広がると書いています。背景には、AIのコーディング支援ツール(Claude Code、Codex、Lovable、Replitの名前を挙げています)でアプリを作る人が増えたことを挙げています。
なぜ起きるか(RLSとキーの説明)
RLS(行レベルセキュリティ)
Supabaseは、Postgresというデータベースを、画面や外部のプログラムから使えるサービスです。アプリは、データベースの表を、Data API(自動で作られるREST・GraphQLの窓口)を通して読み書きします。
RLSは、表の行ごとに「誰が読める・書ける」を決めるデータベースの仕組みです。Supabaseの公式の資料は、次のように書いています。
A table in an exposed schema without RLS is readable and writable by any role with a grant on it. Enable RLS on every table in an exposed schema.
出典: Supabase Docs「Row Level Security」
意味は、公開されたスキーマの表は、RLSが無いと、権限(グラント)を持つロールなら読み書きできる、です。ロールは、Supabaseがリクエストに割り当てる利用者の区分で、ログインしていない人はanon、ログイン済みの人はauthenticatedです。
SupabaseのRLSのページ。公開スキーマの全ての表でRLSを有効にするよう求める注意書き出典: Supabase 公式ドキュメント「Row Level Security」(引用)
RLSを有効にするだけでは、足りないことがあります。RLSを有効にしたうえで、ポリシー(行ごとの規則)を書く必要があります。UpGuardは、ポリシーはあるが制限が足りないものも、漏えいの原因として挙げています。公式の資料にも、anonに対してusing ( true )というポリシーを書くと、ログインしていない全員に、権限が届く行をすべて見せる、とあります。
2種類のキー
アプリがSupabaseに入るときは、キーを使います。公式の資料は、キーを2種類に分けています。
| キー |
使う場所 |
公式の説明 |
| publishable(公開用。旧anon) |
ブラウザー、スマホアプリなど利用者の手元に届く所 |
誰でも読める前提。RLSが許す範囲にだけ届く |
| secret(秘密。旧service_role) |
サーバー、Edge Functionなど自社が管理する所 |
RLSを素通りする。ブラウザーや配布するアプリ、ソース管理に入れてはならない |
公開用のキーが見えること自体は、設計どおりです。問題は、RLSが無いか甘いときに、そのキーで読めてしまうことです。UpGuardは、公開用のキーを秘密のキーのように使う例も、原因に挙げています。
表の作り方によって、既定の状態が違う
UpGuardは、Supabaseが、管理画面のTable Editorで作る表にはRLSを既定で有効にするようになった一方、APIから(プログラムから)作る表は、既定では有効にならない、と書いています。AIのコーディング支援ツールは、後者の形で表を作ります。
公式の資料も、「Supabaseの管理画面で作った表はRLSが既定で有効。SQLエディターなど別の道具で作った表は、自分で有効にする」と書いています(Securing your API)。
影響する会社・しない会社
- 影響する: 自社の部署や委託先が、Supabaseでアプリ(社内ツール、予約、会員サイト、問い合わせ管理など)を作って、公開している会社。RLSの設定を、誰も確かめていないものが当たります。
- 確認が要る: 部署や委託先が何でアプリを作ったかを、情シスが把握していない会社。洗い出しから始めます。
- 影響しない: Supabaseを使っていない会社。
情シスが今日やること
- 使っているかを洗い出す。部署、子会社、委託先に「Supabaseで作ったアプリはあるか」と聞きます。契約のメールや、クレジットカードの明細、経費の請求にSupabaseの名前が無いかも見ます(編集部の補足)。
- 見つかったら、プロジェクトの所有者を決める。誰のアカウントで作られ、誰が管理画面に入れるかを確かめます。個人のアカウントなら、会社の管理に移す方針を決めます(編集部の補足)。
- 管理画面のSecurity Advisorを開く。公式のAdvisorsの資料は、StudioにHealth・Security・Performanceの3つのAdvisorがあると書いています。検査の一覧には「rls disabled in public」(公開スキーマでRLSが無効)、「policy exists rls disabled」「rls enabled no policy」「permissive rls policy」などがあります。
- 表と、キーの使い方を確かめる。Database > PoliciesでRLSの状態を見ます。キーは、Settings > API Keysで確かめます。secret(旧service_role)のキーが、ブラウザーのコードや配布物に入っていないかを、開発者に聞きます。
- 個人情報があれば、対応を決める。RLSが無い表に個人情報があるなら、開発者に有効化とポリシーの追加を頼み、個人情報の取扱いの担当者にも相談します。すでに読まれたかは、この記事では分かりません。
委託先・社内の開発者への聞き方
そのまま使える質問です(編集部の補足)。
- Supabaseを使っていますか。プロジェクトは、いくつありますか。誰のアカウントですか。
- 公開しているスキーマの表は、すべてRLSが有効ですか。Security Advisorに指摘は残っていませんか。
- ポリシーに
using ( true )のような、全員に見せる設定はありませんか。それは、公開してよいデータだけですか。
- secret(service_role)のキーは、サーバーの中だけで使っていますか。ブラウザーやアプリの中に入れていませんか。
- パスワードや認証トークンを、平文で保存していませんか。
自社のプロジェクトを確かめるのは、管理画面からにします。他社のサイトを外から試すことは、しないでください。
Supabase側の予定
公式のchangelogは、2026年4月28日に、新しい表をData APIから自動で読み書きできないようにする変更を予告しました。2026年10月30日に、既存のプロジェクトにも適用するとしています。ただし、すでにある表は影響を受けず、いまの権限のまま残ると書かれています。古い表の確認は、この変更では代わりになりません。10月30日より後に作る表は、権限を明示して与えないとData APIから見えなくなります。開発者がこの変更を知っているかも、聞いておきます(編集部の補足)。
公式の資料は、古い形式のキー(anon、service_role)を2026年末までに廃止する予定とも書いています。新しい形式のキーへ切り替える予定も、あわせて聞きます(編集部の補足)。
書かれていないこと
- 調べたサイトの名前。報告は、5例を含め、すべて伏せています。
- 日本のサイトの数や社名。
- 見つかった16,326件のうち、実際に悪用されたものの数。報告は、悪用の有無を書いていません。
- 中身を数えた件数。報告は表の構造から見積もっています。図は「表の割合」で、本文の「データベースの半分超」とは単位が違います。
- Supabaseの公式の反応。2026年10月13日の時点で、この調査に応じた公式の発表は見つかりませんでした。
- CVE-2025-48757は、CVE.orgの記録では、Lovableの行レベルセキュリティの設定の不十分さに付いた番号で、2025年5月30日に公開されました。供給元は、各利用者がアプリのデータを守る責任を負うとして、争っています。UpGuardはこの番号を、Supabaseの設定の不備の例として挙げています。Supabaseの製品の脆弱性として登録されたものではありません。
