フック
Supabase プロジェクトを保護するには、API キー管理、データベース セキュリティ、およびストレージ権限に重点を置いた多層アプローチが必要です。 [S1] 行レベル セキュリティ (RLS) が不適切に構成されたり、機密キーが公開されたりすると、重大なデータ漏洩インシデントが発生する可能性があります。 [S2] [S3]
何が変わったのか
この調査では、公式アーキテクチャ ガイドラインに基づいて、Supabase 環境の中核となるセキュリティ制御を統合します。 [S1] これは、デフォルトの開発構成から運用環境が強化された状態への移行、特にアクセス制御メカニズムに焦点を当てています。 [S2] [S3]
影響を受けるのは誰ですか
Supabase をサービスとしてのバックエンド (BaaS) として利用するアプリケーション、特にユーザー固有のデータまたはプライベート資産を処理するアプリケーションが影響を受けます。 [S2] クライアント側バンドルに service_role キーを含める開発者、または RLS を有効にしない開発者は、高いリスクにさらされます。 [S1]
問題の仕組み
Supabase は、PostgreSQL の行レベル セキュリティを利用してデータ アクセスを制限します。 [S2] デフォルトでは、テーブルで RLS が有効になっていない場合、anon キー (多くの場合パブリック) を持つユーザーはすべて、すべてのレコードにアクセスできます。 [S1] 同様に、Supabase ストレージには、ファイル バケットに対して操作を実行できるユーザーまたはロールを定義する明示的なポリシーが必要です。 [S3]
攻撃者が得られるもの
公開 API キーを所有する攻撃者は、RLS が欠落しているテーブルを悪用して、他のユーザーに属するデータの読み取り、変更、または削除を行う可能性があります。 [S1] [S2] ストレージ バケットへの不正アクセスは、プライベート ユーザー ファイルの漏洩や重要なアプリケーション資産の削除につながる可能性があります。 [S3]
FixVibe がそれをテストする方法
FixVibe は、Supabase チェックの一部としてこれをカバーするようになりました。 baas.supabase-security-checklist-backfill は、パブリック Supabase ストレージ バケット メタデータ、匿名オブジェクト リストの公開、機密性の高いバケットの名前付け、およびパブリックの非境界からの非バインド ストレージ シグナルをレビューします。関連するライブ チェックでは、サービス ロール キーの公開、Supabase REST/RLS ポスチャ、不足している RLS のリポジトリ SQL 移行を検査します。
何を修正するか
データベース テーブルでは常に行レベル セキュリティを有効にし、認証されたユーザーに対して詳細なポリシーを実装します。 [S2] 「anon」キーのみがクライアント側のコードで使用され、「service_role」キーはサーバー上に残るようにしてください。 [S1] ストレージ アクセス制御を構成して、ファイル バケットがデフォルトでプライベートになり、定義されたセキュリティ ポリシーを通じてのみアクセスが許可されるようにします。 [S3]