ClearedToShip
high

Supabase RLS のベストプラクティス

何が問題か

RLS の有効化は、仕事の半分にすぎません。緩すぎる、または誤ったポリシーは、RLS が「オン」でもデータを露出させたままにします。これらが、Supabase の行レベルセキュリティに本当にデータを守らせるためのプラクティスです。

ステップ・バイ・ステップ

  1. 1

    デフォルトで拒否し、明示的に許可する

    すべてのテーブルで RLS を有効にしてアクセスをデフォルトで拒否し、その上で狭いポリシーを追加してください。プライベートなデータを持つテーブルに「true」や「すべて許可」のポリシーを決して使わないでください。

  2. 2

    ポリシーをユーザーにスコープする

    auth.uid() を使って行を所有者に限定してください。例:USING (auth.uid() = user_id)。操作(select/insert/update/delete)ごとに別々のポリシーを書き、書き込みには WITH CHECK を使ってください。

  3. 3

    権限昇格を防ぐ

    service-role キーはサーバー側だけに保ってください。これは RLS を回避します。ポリシーを迂回してデータを漏らすビューや SECURITY DEFINER 関数を露出させないでください。

  4. 4

    匿名としても、ユーザーとしてもテストする

    匿名リクエストが何も返さないこと、そしてあるユーザーが別のユーザーの行を読み書きできないことを確認してください。無料の RLS チェッカーを再実行して確認しましょう。

修正するだけでなく、検証もしてほしいですか?

修正は第一歩にすぎません。ClearedToShip のレビューなら、修正が本当に有効かを確認し、ローンチのための署名入り・保険付きのクリアランスを発行します。早期アクセスに参加:

無料ローンチ準備スキャン
無料スキャンを受ける