high
Supabase RLS のベストプラクティス
何が問題か
RLS の有効化は、仕事の半分にすぎません。緩すぎる、または誤ったポリシーは、RLS が「オン」でもデータを露出させたままにします。これらが、Supabase の行レベルセキュリティに本当にデータを守らせるためのプラクティスです。
ステップ・バイ・ステップ
- 1
デフォルトで拒否し、明示的に許可する
すべてのテーブルで RLS を有効にしてアクセスをデフォルトで拒否し、その上で狭いポリシーを追加してください。プライベートなデータを持つテーブルに「true」や「すべて許可」のポリシーを決して使わないでください。
- 2
ポリシーをユーザーにスコープする
auth.uid() を使って行を所有者に限定してください。例:USING (auth.uid() = user_id)。操作(select/insert/update/delete)ごとに別々のポリシーを書き、書き込みには WITH CHECK を使ってください。
- 3
権限昇格を防ぐ
service-role キーはサーバー側だけに保ってください。これは RLS を回避します。ポリシーを迂回してデータを漏らすビューや SECURITY DEFINER 関数を露出させないでください。
- 4
匿名としても、ユーザーとしてもテストする
匿名リクエストが何も返さないこと、そしてあるユーザーが別のユーザーの行を読み書きできないことを確認してください。無料の RLS チェッカーを再実行して確認しましょう。
修正するだけでなく、検証もしてほしいですか?
修正は第一歩にすぎません。ClearedToShip のレビューなら、修正が本当に有効かを確認し、ローンチのための署名入り・保険付きのクリアランスを発行します。早期アクセスに参加: