Supabaseのアクセスルールを、正しく

よくある問題

何で作ったかにかかわらず、レビューが追いつかない速さで育ったアプリによく見られる問題です。ほとんどは、今の環境のまま直せます。

1. RLSのないテーブル

   anonキーは、設計どおりすべてのブラウザに配信されます。公開されたスキーマにRLSのないテーブルがあれば、そのキーだけで読み取れ、場合によっては変更もできます。

   Supabaseを使うLovable製のアプリが、行レベルセキュリティ（RLS）のないまま公開された事例があり、CVE-2025-48757として登録されています。 Wikipedia（英語）：Lovable

2. フロントエンドに置かれた、置いてはいけないキー

   service_roleキーは、RLSを完全に迂回します。サーバーかEdge Functionに置くもので、ブラウザ向けのバンドル、モバイルアプリ、公開リポジトリに置いてはいけません。

   Moltbookでは、フロントエンドに置かれたSupabaseのキーを通じて、150万件のAPIトークンが漏えいしました。 Wikipedia（英語）：Moltbook

3. 広すぎるポリシー

   単にtrueを返すポリシーや、認証済みの利用者なら誰でも許可するポリシーは、利用者どうしの間では何も守っていません。利用者自身が設定できる列と比べるポリシーは、回避されるおそれがあります。

4. ストレージと関数

   公開のストレージバケット、有効期限の長い署名付きURL、呼び出し元より強い権限で動くデータベース関数は、どれもテーブルのポリシーで守るはずだったデータに届いてしまいます。

5. 認証の設定

   招待した利用者向けのアプリなのに誰でもサインアップできる、メールアドレスの確認が無効になっている、リダイレクトURLがどのサイトでも許可されている、といった設定です。

Supabaseのアプリで監査が確認すること

コード・プロダクト監査では、外から見える部分だけでなくコードそのものを読み、すべての指摘を事業への影響で順位づけします。Supabaseのアプリの場合は、次の点を確認します。

• APIで公開されているすべてのテーブル、ビュー、関数と、それを守るポリシー。誰が何を見るべきかと照らし合わせて確認します。
• どのキーがどこに配信されているか。ブラウザにはanonキー、service_roleキーは漏れうる場所のどこにもないこと。
• ストレージバケットのポリシーと、署名付きURLの有効期限。
• 認証の設定。サインアップ、確認メール、パスワードの再設定、リダイレクトURL、プロバイダー。
• Edge Functionとそのシークレット。
• マイグレーション、環境、バックアップ。スキーマがどう変わり、どう復元できるか。
• プロダクトと事業の目標。お話をうかがい、すべての指摘を事業にとっての意味で順位づけします。

公開中のアプリを1日で確認する、固定価格のローンチチェックもご用意しています。認証、RLS（行レベルセキュリティ）とデータアクセス、シークレットを確認し、リスクの大きいものから5件を30分のお打ち合わせでご説明します。 ローンチチェックについて

今の環境のまま、本番で通用する状態へ

基本のご提案は、今のプロジェクトのルールを引き締めることです。別のデータベースへの移行は、監査でその費用に見合うとわかった場合にだけご提案します。

Supabaseのアプリを、まず無料チェックで

無料チェックは、配信されているJavaScriptに含まれるキー、ヘッダー、HTTPS、バージョンなど、アプリがすでに外に見せているものをスキャンし、2営業日以内にAaronが結果を確認します。メールでのご確認と、アプリの所有者であることの確認が済んでから実行します。