TL;DR
はい、プラットフォームは安全です。SupabaseはSOC 2 Type 2とISO 27001の認証を取得し、保管時のデータをAES-256、転送時のデータをTLSで暗号化し、TeamプランとEnterpriseプランでHIPAA契約も結びます。ただし、あなたのプロジェクトは別の問いです。Supabaseの責任共有モデルでは、テーブルへのアクセス、API keys、認証の設定はあなたの担当で、プラットフォームはその設定のとおりに動きます。私のローカルのテストテーブルでは、設定1つで、公開キーが0行を取るか3行すべてを取るかが決まりました。
Denysです。フルスタック・AIエンジニアで、私が作る、あるいは直すアプリのほとんどはSupabaseで動いています。クライアントが「Supabaseは安全ですか？」と聞くとき、実際には「自分のデータは安全ですか？」と聞いています。この2つは答えが違うので、この記事では1つずつ見ていきます。
Supabaseのプラットフォームは安全？
プラットフォーム側は第三者の監査を受けています。2026年10月23日に読んだSupabaseのセキュリティページとセキュリティのドキュメントによると、次のとおりです。
| コントロール | Supabaseの記載 |
|---|---|
| SOC 2 Type 2 | 毎年監査を受ける。レポートはTeamとEnterpriseの顧客が利用可能 |
| ISO 27001 | 認証取得済み。証明書はTeamとEnterpriseの顧客が利用可能 |
| HIPAA | 署名済みのBusiness Associate AgreementとHIPAAアドオンで対応。Teamプラン以上 |
| 暗号化 | 保管時はAES-256、転送時はTLS。アクセストークンとキーはアプリケーションレベルでも暗号化 |
| バックアップ | 有料プロジェクトは毎日。Point in Time RecoveryはProプラン以上でアドオン |
| データの所在地 | データベース、Auth、Storageは、選んだAWSリージョンに留まる |
これらは、あなたが開けたままにしたテーブルを守ってくれません。SOC 2のガイドははっきり書いています。Supabaseのコンプライアンスは、Supabaseの管理外にあるものには引き継がれません。
あなたの担当は何？
Supabaseの責任共有モデルは、常にあなたの担当となるものを挙げています。アカウント、データベースとそのテーブルへのアクセス管理、データ、そしてSecurity Advisorが出す警告を含むセキュリティコントロールの適用です。実際には、設定は4つの層になります。
- 誰がテーブルに触れるか。 grantは、
anonとauthenticatedがそもそもテーブルに届くかを決めます。どの行かはRLSポリシーが決めます。 - どのキーをどこに置くか。 publishable keyは設計上公開で、secret keyはRLSを迂回します。2つの比較はSupabase anon keyとservice role keyの違いにあります。
- 認証の設定。 メール確認、leaked password protection（Proプラン以上）、パスワードの最小長、MFA、redirect URLs、CAPTCHAです。
- データベースの周辺すべて。 Storageのバケットとそのポリシー、
SECURITY DEFINER関数、secret keyを使うEdge Function、そしてData APIがどのスキーマを公開するかです。
設定1つでどれだけ変わる？
ローカルのSupabaseスタック（CLI 2.109.1、Postgres 17.6、PostgREST 14.14）で、偽の注文3行のテーブルに対して、ブラウザと同じようにpublishable keyで同じリクエストを実行しました。
| テーブルの設定 | 公開キーで取れたもの |
|---|---|
| RLSオフ | 3行すべて。INSERTは201 Createdを返した |
| RLSオン、ポリシーなし | [] |
RLSオン、ポリシーusing (true) |
3行すべて |
anonへのgrantなし |
42501 permission denied |
同じプラットフォーム、同じ暗号化、同じ認証。違いはSQLの1行です。だから「安全なプラットフォーム」と、データが漏れるアプリは矛盾しません。CVE-2025-48757では、Lovableのショーケースアプリ1,645件のうち170件が公開キーにデータを返していましたが、すべて同じ監査済みのプラットフォーム上のものです。
Supabaseはデフォルトで安全になってきている？
はい、段階的に。2026年4月28日のSupabaseのchangelogには、RLSをデフォルトでオンにするトグル、Data APIの公開バッジ、テーブル単位の細かなgrant、スキーマ列挙の制限が挙げられています。最も大きい変更は2026年10月30日に来ます。既存プロジェクトの新しいテーブルには、Data APIのgrantが自動で付かなくなるので、うっかり忘れたテーブルは、行の代わりに42501を返します。既存のテーブルはgrantを維持するので、すでに開いているものはこれでは直りません。従来のanonとservice_roleのキーも、publishable keyとsecret keyに置き換える形で2026年末までに非推奨になります。新しいsecret keyは、ブラウザからのリクエストを拒否します。
切り替えで他に何が壊れるか、事前の確認方法はSupabase 10月30日のgrant変更：壊れる点と確認方法にまとめました。
自分のプロジェクトをどう確認する？
まずSupabase自身のSecurity Advisorを使い、すべての警告を修正します。そのうえで、それがカバーしないものを確認します。
- 無料のSupabase セキュリティチェックを実行します。読み取り専用で接続し、OWASP Top 10:2025に対応する46のルールでプロジェクトを評価します。RLS、ポリシー、ビュー、関数、grant、ストレージ、認証の設定が対象で、各指摘に修正SQLが付きます。
- 2社の2人のユーザーでテストします。どの行が誰のものかをスキャナーは知りません。テストの方法はLovableアプリのセキュリティチェックリストにあります。
- アプリにロールと権限画面があるなら、Supabase RLSのテスト方法のように、権限のチェックボックスが表示どおりに動くことを証明します。
つまり、Supabaseはデータを置く場所として安全で、データを非公開に保つ道具も用意されています。実際に非公開のままかどうかは、あなたのスキーマと設定で決まります。