RLSだけで良いのか、サーバーサイド認証を入れるべきか
【お先に結論】RLSはシンプルなアクセス制御には有効ですが、他人データの更新・削除や複雑なトランザクションが必要なケースでは、サーバーサイド認証を使用すべきだと考えています。
目次
- RLSとは：Supabaseにおける基本機能
- RLSが有効なケース【具体例】
- RLSの限界と注意点
- サーバーサイド認証を入れるべきケースと理由
- 【比較表】RLSとサーバーサイド認証の使い分け
- まとめ：シンプル×安全な設計の考え方
1. RLSとは：Supabaseにおける基本機能
Row Level Security（RLS）とは、PostgreSQLが持つデータ行単位のアクセス制御機能です。
各データ行に対して権限を設定するため、細やかな管理が可能で、supabaseもRLSを推しています。
RLSを有効化することで以下が実現できます。
- 各ユーザごとにアクセス可能なデータ行を制限できる
auth.uid()を活用し、ユーザ単位の制御が簡単に記述可能- クライアントサイドからの直接クエリ発行でも、RLSが有効に働くため安全性が高い
2. RLSが有効なケース
RLSだけで十分なケースは以下のようなシンプルなアクセスパターンに限定されると考えます。
具体例
- ユーザ自身のデータのみ閲覧・編集できるアプリ
（例：プロフィール管理、ToDoリスト、個人メモ） - ユーザ自身のデータは閲覧・編集できて、他人のデータを「閲覧のみ」できるアプリ
（例：簡単なブログアプリ）
3. RLSの限界と注意点
便利なRLSですが、以下のケースでは設計が破綻しやすいため注意が必要です。
1. 他人データの更新・削除
他人のデータを編集・削除する場合（特に管理者ユーザなど）
- ポリシー記述が肥大化し、バグの温床に
- CHECK制約やTriggerに過度に依存すると、保守が難しくなる
2. 複雑なトランザクションが多いシステム
複雑なトランザクションをsupabaseで実現するにはSQL関数の「RPC」を利用します。ただし、トランザクションが多いシステムだとRPCの数は膨れ上がり保守が難しくなります。
この場合は、prismaやdrizzleなどのORMを入れてしまった方が楽になる場面が多々あります。
4. サーバーサイド認証を入れるべきケースと理由
RLSでは難しい場合は、Next.jsなどのバックエンドをちゃんと作るのが推奨です。
ちゃんとバックエンドを組み、prismaやdrizzleといったORMを使いましょう。RLS + RPCよりも圧倒的に可読性・保守性が上がります。
エンドポイントが増えた場合にもRLS管理より楽です。
supabase-jsとService role keyを使いバックエンド構築する手もありますが、こちらはトランザクションが扱えないため非推奨です。
5. 【比較表】RLSとサーバーサイド認証の使い分け
| ユースケース | RLSのみ対応 | サーバーサイド認証推奨 |
|---|---|---|
| 自身のデータの閲覧・編集 | ✅ | ❌ |
| 自身のデータの閲覧・編集と他人データの「閲覧のみ」 | ✅ | ❌ |
| 他人データの更新・削除 | ❌ | ✅ |
| 複雑なトランザクションが多いシステム | ❌ | ✅ |
6. まとめ：シンプル×安全な設計の考え方
最後に、設計判断のポイントを整理します。
設計方針のステップ
- シンプルなアプリならRLSだけで十分
- 管理者権限や複雑なトランザクションが必要ならサーバーサイド認証を併用
私が開発したアプリもSupabaseを使っております！
インストールしていただけると泣いて喜びます😭
https://apps.apple.com/jp/app/firelife-焚き火で目標達成-タスク管理/id6747326449
