← Back to list

supabase-rls
by shoma-endo
⭐ 0🍴 0📅 Jan 18, 2026
SKILL.md
name: supabase-rls description: Supabase RLS パフォーマンス最適化。セキュリティ境界と最適化フィルタの区別、および堅牢な関数定義を規定。 metadata: short-description: 完全同期版:Supabase RLS 実装規約
Supabase RLS パフォーマンス & ベストプラクティス
このスキルは、Supabase の Row Level Security (RLS) を安全かつ高効率に実装するための「唯一の正解 (SSoT)」を定義します。
命名規則・実装ガイドライン
1. パフォーマンス最適化
- インデックス:
USING句で使用されるカラム(user_id,org_id等)には必ず B-tree インデックスを作成してください。 - initPlan (キャッシュ):
auth.uid()等の JWT 関数を(SELECT auth.uid())でラップし、実行計画での値のキャッシュを有効にすることを推奨してください。
2. セキュリティ境界の定義
- 重要: コード上(
SupabaseService等)での.eq()フィルタは「パフォーマンス最適化とクエリの意図明示」のためであり、セキュリティ境界は常に RLS 側で担保されなければなりません。
3. SECURITY DEFINER の安全策
- [WARNING] 権限昇格を防ぐため、以下の措置を必須としてください。
SET search_path = publicを明示的に指定する。- 関数内での参照は
public.table_nameのようにスキーマ名で修飾する。 - 入力検証の使い分け:
- RETURN false: 値の欠損(NULL 等)や権限のないデータへのアクセスなど、通常の「許可しない」結果として扱える場合に使用。
- RAISE EXCEPTION: セキュリティ上の重大な違反や、予期しない致命的な不正値など、処理を即座に中断すべき場合に使用。
4. マイグレーションフロー
- RLS の変更は必ず
supabase/migrations/配下に SQL ファイルとして隔離し、ロールバック(DROP POLICY ...)の手順をコメントで残してください。
安全な実装例
-- 1. 最適化されたポリシー
CREATE POLICY "Secure item access" ON public.items
FOR SELECT USING (
user_id = (SELECT auth.uid())
);
-- 2. 堅牢な SECURITY DEFINER 関数
CREATE OR REPLACE FUNCTION public.check_access(target_id uuid)
RETURNS boolean
LANGUAGE plpgsql
SECURITY DEFINER
SET search_path = public
AS $$
BEGIN
-- 1. 基本的な入力検証(運用リスク回避のため false を返す)
IF target_id IS NULL THEN
RETURN false;
END IF;
-- 2. ロジック実行(明示的なスキーマ修飾と initPlan 活用)
RETURN EXISTS (
SELECT 1 FROM public.records
WHERE id = target_id
AND owner_id = (SELECT auth.uid())
);
EXCEPTION
-- 3. 予期せぬ致命的エラーのみ例外を投げる
WHEN OTHERS THEN
RAISE EXCEPTION 'Internal security function error: %', SQLERRM;
END;
$$;
Score
Total Score
50/100
Based on repository quality metrics
✓SKILL.md
SKILL.mdファイルが含まれている
+20
○LICENSE
ライセンスが設定されている
0/10
○説明文
100文字以上の説明がある
0/10
○人気
GitHub Stars 100以上
0/15
○最近の活動
3ヶ月以内に更新がある
0/10
○フォーク
10回以上フォークされている
0/5
✓Issue管理
オープンIssueが50未満
+5
✓言語
プログラミング言語が設定されている
+5
○タグ
1つ以上のタグが設定されている
0/5
Reviews
💬
Reviews coming soon