Supabase の Row Level Security ポリシーとテーブル権限を点検し、「意図せず他人のデータが見える/書ける」状態になっていないかを確認します。
■ 点検する項目
・RLS が有効化されていないテーブルの検出
・auth.uid() の参照漏れ、USING と WITH CHECK の書き分け
・anon / authenticated ロールに与えられた権限の過不足
・Storage バケットのポリシー
・service_role キーがクライアント側に露出していないか
・ポリシーが原因のパフォーマンス問題(インデックス不足)
■ お渡しするもの
・検出した問題の一覧(深刻度つき)
・修正用の SQL
・「なぜ危いか」の説明(再発防止のため)
■ 私について
Supabase(Auth / DB / RLS / Storage)を個人開発アプリの本番環境で運用しています。ローカルの supabase CLI 環境からマイグレーション運用まで、実際に手を動かして使っています。
■ 進め方
1. スキーマ定義とポリシーの定義をお送りください
2. 1本ずつ読んで、意図と実際の振る舞いのずれを洗い出します
3. 問題の一覧と修正 SQL をお渡しします
・スキーマ定義(supabase db dump の出力、またはマイグレーションファイル)をご用意ください。
・本番の service_role キーやパスワードは送らないでください。点検には必要ありません。
・テーブルごとに「誰が読めるべきか」の意図をあわせてお知らせください。意図が分からないと、抜けなのか仕様なのか判別できません。
・対応は Supabase の RLS・権限・Storage ポリシーの点検と修正 SQL の提供までです。アプリ側の実装修正は含みません。