影響
行レベル セキュリティ (RLS) が適切に適用されていない場合、攻撃者はアプリケーション ロジックをバイパスしてデータベース内のレコードを読み取り、更新、または削除する可能性があります。これにより、公開匿名の API キーのみにアクセスできるユーザーに個人識別情報 (PII) や機密アプリケーション データが公開されることがよくあります。
根本原因
Supabase は、Postgres 行レベル セキュリティを使用してデータベース レベルでデータ アクセスを管理します。これは、データ [S1] を保護するための基本です。 Next.js 環境では、開発者は、サーバー側のレンダリング中にセキュリティを維持するために Cookie とセッションを正しく処理する Supabase クライアントを作成する必要があります。脆弱性は通常、次の場合に発生します。
- テーブルは RLS を有効にせずに作成され、公開 anon キー [S1] を介してアクセスできるようになります。
- Supabase クライアントの構成が Next.js で間違っており、ユーザー認証トークンをデータベース [S2] に正しく渡すことができません。
- 開発者が誤ってクライアント側コードで
service_roleキーを使用すると、すべての RLS ポリシー [S1] がバイパスされます。
具体的な修正
- RLS を有効にする: Supabase データベース [S1] 内のすべてのテーブルに対して行レベル セキュリティが有効になっていることを確認します。
- ポリシーの定義:
SELECT、INSERT、UPDATE、およびDELETE操作用の特定の Postgres ポリシーを作成し、ユーザーの UID [S1] に基づいてアクセスを制限します。 - SSR クライアントを使用する:
@supabase/ssrパッケージを実装して、サーバー側の認証とセッション永続性 [S2] を正しく管理するクライアントを Next.js に作成します。
FixVibe がそれをテストする方法
FixVibe は、デプロイされたアプリとリポジトリのチェックを通じてこれをすでにカバーしています。パッシブ baas.supabase-rls モジュールは、同じ生成元の JavaScript バンドルから Supabase URL と非キーのペアを検出し、PostgREST にパブリック テーブル メタデータを要求し、限定された読み取り専用選択を実行して、顧客データを変更することなく匿名データの公開を確認します。また、リポジトリ スキャンでは、ENABLE ROW LEVEL SECURITY を使用せずにパブリック テーブルを作成する SQL 移行にフラグを立てるために repo.supabase.missing-rls も実行され、シークレット スキャンでは、ブラウザーに到達する前にサービス ロール キーの露出を探します。