影響
行レベル セキュリティ (RLS) の実装に失敗すると、パブリック テーブルがアノン境界 [S1] を通じて公開されるときに、認証されていない攻撃者が Supabase データベースからデータをクエリすることができます。 Next.js アプリケーションは通常、クライアント側コードで Supabase anon キーを公開するため、攻撃者はこのキーを使用してデータベースに対して直接 REST API 呼び出しを行い、意図したアプリケーション ロジックをバイパスし、ユーザーの機密情報 [S2] にアクセスする可能性があります。
根本原因
デフォルトでは、Supabase の Postgres テーブルでは、パブリック アクセス [S1] を防ぐために行レベル セキュリティを明示的にアクティブ化する必要があります。開発者がテーブルを作成したが、RLS を有効にするのを忘れた場合、または制限ポリシーの定義に失敗した場合、データベースはプロジェクトの anon キー [S1] を所有するユーザーにデータを公開する可能性があります。 Next.js アプリケーションでは、サーバー側のレンダリングとクライアント側のフェッチにも、認証されたユーザー コンテキストがデータベース層 [S2] に到達するように、慎重な Supabase クライアント セットアップが必要です。
具体的な修正
- RLS を有効にする: アプリ データ [S1] を保存するすべてのパブリック テーブルに対して
ALTER TABLE "your_table_name" ENABLE ROW LEVEL SECURITY;を実行します。 - ポリシーの定義: ユーザーの認証ステータスに基づいてアクセスを制限する特定のポリシー (
CREATE POLICY "Users can see their own data" ON your_table_name FOR SELECT USING (auth.uid() = user_id);[S1] など) を作成します。 - 安全なサーバー側クライアント: Next.js を使用する場合、サービス ロール クライアントをサーバーのみに保ち、ユーザー [S2] にデータを返す前に所有権フィルターを適用します。
FixVibe がそれをテストする方法
FixVibe は、baas.supabase-rls を通じて読み取り専用の Supabase RLS チェックをすでに実行しています。スキャナーは、同じ生成元の JavaScript バンドルから Supabase プロジェクト URL とパブリック anon キーを検出し、PostgREST にパブリック テーブル メタデータを要求し、制限された読み取り専用選択を試みて、データがユーザー セッションなしで公開されているかどうかを確認します。サービスロールの資格情報の挿入、更新、削除、または使用は行いません。リポジトリ スキャンでは、repo.supabase.missing-rls を介してこれを早期に検出することもできます。これは、ENABLE ROW LEVEL SECURITY を使用せずにパブリック テーブルを作成する SQL 移行にフラグを立てます。