Supabase を本番で使う前に見るのは、4つです。すべての公開テーブルで RLS（行単位のアクセス制御）が有効で、ポリシーが意図どおりか。ブラウザに置くキーが公開用だけか。バックアップがプランごとにどうなっているか。開発と本番でプロジェクトを分けているか。仕様は変わるので、この記事は公式ドキュメントを2026年10月に確認した内容です。
なぜ、RLS から見るのか
RLS（Row Level Security）は、データベースの中で「この行は、この人だけが見てよい」を決める仕組みです。たとえば注文の表に、Aさんの注文と Bさんの注文が入っていても、RLS で「自分の注文だけ」と決めておけば、Aさんに Bさんの行は返りません。
Supabase は、ブラウザやアプリから、データベースに直接つながる API（Data API）を使えます。公式ドキュメントは、次のように説明しています。
- public スキーマのテーブルは、Supabase の API からアクセスできます。
- RLS が有効でない public テーブルは、プロジェクトの URL を知っていれば誰でも、行の作成・読み取り・更新・削除ができる状態になり得ます。
つまり、ログイン画面があっても、アプリの画面で見えないようにしていても、データベース側の RLS が無ければ、守られていないことがあります。画面の側で防げなくても、データベースの側で止める。その最後の守りが、RLS です。
1. RLS: 有効かどうかと、何が見えるか
公式ドキュメントで確認できたこと
- Dashboard から作ったテーブルは、RLS が既定で有効です。
- RLS を有効にすると、ポリシーを作るまで、公開用のキーでは API からデータが見えなくなります。
- 公式は「公開しているスキーマのすべてのテーブルで RLS を有効にする」ことを求めています。
- ビュー（view）は、既定では RLS を迂回します。公式は、ビューが通常 postgres ユーザーで作られるためと説明しています。
- 既存のプロジェクトでは、public に作ったテーブルに、
anon・authenticated・service_roleの3つのロールへの権限が、既定で付きます。Supabase は、この既定を、公開が明示的な選択になるように変更中と書いています。ただし、プロジェクトによって異なるため、自分のプロジェクトでの状態を確かめる必要があります。
確かめ方
- RLS が無効のテーブルがないか。 Supabase のダッシュボードには、セキュリティ面の指摘を出す Advisor があります。公式は、public テーブルで RLS が無効な場合を重大な指摘（lint 0013）として扱っています。
- SQL やマイグレーションで作ったテーブルも、有効か。 Dashboard で作ったテーブルは既定で有効と書かれていますが、SQL で作った場合の既定は、今回確認した公式ページには書かれていませんでした。自分の目で、全テーブルを確かめてください。
- ビューを公開していないか。 使っているなら、RLS が効いているかを確かめます。
- ポリシーが、意図どおりか。 有効になっていても、ポリシーが緩ければ、他人のデータが見えます。公式は、テーブルごとにテストを書いて
supabase test dbで実行するよう案内し、「テストが通るまでは、ポリシーが意図どおりかは分からない」と書いています。
テストを書く前に、まず実際に試すこともできます。アカウントを2つ作り、片方でログインしたまま、もう片方のデータを指定してみる方法は、ログインと権限の制御に書いています。
2. キー: ブラウザに置いてよいもの、いけないもの
Supabase には、API キーの種類があります。公式ドキュメントでは、次のように整理されています。
| キー | 位置づけ | 置いてよい場所 |
|---|---|---|
publishable キー（従来の anon キー） |
公開用 | ブラウザ、アプリ、ソースコードなど。「Safe to expose online」（訳: オンラインで公開しても安全） |
secret キー（従来の service_role キー） |
RLS を迂回する | サーバー側だけ。ブラウザ、配布するアプリ、ソースコードの管理には置かない |
押さえておきたい点は3つです。
- 公開用のキーも、RLS が前提です。 公式は、公開用のキーでは、RLS がクライアントの届く範囲を決める、と説明しています。公開用だから安全、ではありません。
- secret キーは、RLS を迂回します。 公式は「A secret key bypasses every Row Level Security policy you have.」（訳: secret キーは、あなたが設定したすべての Row Level Security ポリシーを迂回します。）と書いています。ブラウザに届くコードに入っていたら、RLS の設定に関わらず、データに触れられます。
- 従来のキーは、廃止予定です。 公式は、
anonとservice_roleのキーを2026年末までに廃止する予定だと書いています。新しい名前のキーへの移行も、本番化の確認に入れてください。
secret キーが漏れた場合、公式は、新しいキーを作って置き換え、漏れたキーはすぐに削除するよう案内しています。漏れたあとの手順は、API キーが漏れたあと、最初にやることにまとめています。キーが外から見える状態の確かめ方は、APIキーがブラウザやコードから見えていないかにあります。
3. バックアップ: プランごとに違う
公式ドキュメントと料金ページで確認できた範囲を、表にまとめます。
| プラン | 日次バックアップ |
|---|---|
| Free | 含まれない（料金ページ）。公式は、CLI の db dump で定期的にエクスポートするよう勧めている |
| Pro | 直近7日分 |
| Team | 直近14日分 |
| Enterprise | 最大30日分 |
そのほか、押さえておきたい点です。
- PITR（Point-in-Time Recovery）は、追加オプションです。 Pro・Team・Enterprise で有効にできます。公式のチェックリストは、データベースが4GB を超える見込みなら有効にするよう案内しています。
- Storage に保存したファイルは、データベースのバックアップに含まれません。 公式は「データベースには、オブジェクトのメタデータしか含まれない」ためと説明しています。画像やアップロードされたファイルを扱うなら、別に考える必要があります。
- 無料プランは、使われないと一時停止されることがあります。 公式の料金ページには「1週間使われないと一時停止」とあり、チェックリストは、一時停止されないことを保証したいなら Pro にするよう案内しています。
バックアップは、あるかどうかより、戻せるかが大事です。戻す練習の考え方は、バックアップと監視に書いています。
4. 開発と本番: プロジェクトを分ける
公式ドキュメントの環境管理のページは、次の構成を示しています。
- 本番とは別に、ステージング用の Supabase プロジェクトを作る。
- 各開発者、各ブランチは、ローカルに自分のデータベースを持てる。
- 構成は、機能ブランチ＝ローカルのデータベース、develop ブランチ＝ステージングのデータベース、main ブランチ＝本番のデータベース。
- データベースの変更は、
supabase/migrationsディレクトリのマイグレーションとして管理し、リリースのときに、リンクしたプロジェクトへ適用する。
Supabase のダッシュボードから直接テーブルを変更していると、開発のつもりの変更が本番に入ることがあります。変更を履歴として残し、本番へは決まった経路で入れる、という分け方の考え方は、開発環境と本番環境の分け方にまとめています。
公式のチェックリストにある、そのほかの項目
公式の「Going into Prod」のページには、次のような項目もあります。
- アカウントを MFA（多要素認証）で守る
- データベースの SSL 強制を有効にする
- データベースへの Network Restrictions（接続元の制限）を設定する
- よく使うクエリに合った索引を用意する
- 負荷テストを行う（できればステージング環境で）
事例: 2つのニュースから
RLS やキーの設定漏れは、実際のニュースにもなっています。2件とも、「ツールが危険」という話ではない点に注意して読んでください。
Lovable で生成されたサイトの RLS 不備（CVE-2025-48757）。 2025年に、Lovable で生成されたサイトで、RLS が不十分なため、認証なしの第三者がデータベースを読み書きできる例が報告されました。この CVE には、**供給元が異議を出している（disputed）**という注記があります。注記は、Lovable の各顧客が、自分のアプリのデータを保護する責任を負う、という趣旨です。つまり、どのツールで作っても、データを守る設定を確かめる役目は、公開する側に残る、という論点です。詳しくはログインと権限の制御にあります。
Moltbook のデータベース露出。 2026年1月、セキュリティ企業の Wiz が、Moltbook のデータベースが外から見える状態だったと報告しました。Wiz の説明では、クライアント側の JavaScript に Supabase の API キーが入っていて、RLS のポリシーが無かったため、そのキーで本番データベース全体にアクセスできました。Wiz は創業者の「コードを1行も書いていない」という発言を引用していますが、AI が直接の原因だとは実証していません。
この2件が示すのは、Supabase に限らず、キーの置き場所と、データ側の権限設定が、別々に必要だということです。
私たちの考え方: ダッシュボードで見えることと、確かめたことは別
私たちも、Supabase を使った案件を手がけています。Supabase は、ダッシュボードで設定の多くが見え、Advisor が指摘もしてくれます。それでも私たちは、他人のデータが見えないことを、実際に試して確かめることを勧めます。RLS が「有効」と表示されていることと、ポリシーが意図どおりに効いていることは、別だからです。
判断の順序は次のとおりです。まず、すべてのテーブルで RLS が有効か。次に、ブラウザに届くキーが公開用だけか。そして、別のアカウントで、見えてはいけないものが見えないか。この3つを、公開前に確かめます。
本番に出す前の、確認リスト
- すべての public テーブルで RLS が有効か（SQL で作ったものも含む）。ビューは公開していないか
- アカウントを2つ作り、他人のデータが見えないか。ログアウトした状態でも試したか
- ブラウザに届くコードに、secret（service_role）キーが入っていないか
- バックアップの有無と、保存日数を、自分のプランで確かめたか。Storage のファイルは別に考えたか
- 開発用と本番用でプロジェクトを分け、本番へはマイグレーションで入れているか
- アカウントの MFA、SSL の強制、接続元の制限を確かめたか
wizgeek にできること
確かめて不安が残ったとき、または確かめ方に自信がないときは、ご相談ください。試作の構成と機能を把握し、認証・データベース・インフラ・セキュリティ・監視のうち何が足りないかを整理して、構成案をお渡しします（本番化の診断：5万円〜、税別）。構成案をもとに、お客様側で実装していただくこともできます。本番化の作業は別途お見積りします。公開後の保守運用は、月10万円〜（税別）です。
公開前に確かめる4点の全体像は、AIで作ったアプリを本番化するにはにまとめています。