【Supabase入門】Row Level Security (RLS) とは？フロントエンドからDBを直接触る時代の必須セキュリティ

Next.jsなどのモダンなフレームワークと組み合わせて、個人開発やプロダクトの立ち上げスピードを劇的に加速させる「Supabase」。

サーバーレスで爆速な開発を実現する上で、絶対に避けて通れない最重要概念が「Row Level Security（RLS）」です。

今回は、Supabase（PostgreSQL）の強力なセキュリティ機能であるRLSについて、なぜ必要なのか、どうやって動くのかを分かりやすく解説します。

RLS（Row Level Security）とは？

RLSとは、データベースの「行（Row）単位」でデータの読み書き権限を制御する機能です。

従来のデータベース全体のアクセス権（テーブルへのアクセス許可など）に加えて、「このユーザーは、このテーブルの『この行』だけを読み書きできる」という、非常にきめ細かいルール（ポリシー）を設定できます。

例えば、posts（投稿）テーブルがあったとします。RLSを設定すると、以下のような制御がデータベースのレイヤーで自動的に行われます。

従来のWeb開発（例えばRuby on Railsなどをバックエンドに挟む構成）では、ブラウザ（フロントエンド）とデータベースの間に「自作のAPI（バックエンド）」が存在していました。悪意のあるリクエストは、このAPIのロジックで弾くのが普通でした。

しかし、Supabaseの最大の特徴は「フロントエンドから直接データベースを読み書きできる（ように見える）」点にあります。

これは開発スピードを圧倒的に引き上げる反面、「APIという関所がないなら、誰でも他人のデータを勝手に読んだり消したりできちゃうのでは？」というセキュリティリスクを生み出します。

その「関所」の役割を、APIではなくデータベースそのもの（PostgreSQL）に持たせるのがRLSの役割です。RLSを有効にしていないテーブルは、初期状態では「誰も読み書きできない」か「誰でもフルアクセス可能」という極端な状態になり、本番環境では非常に危険です。

RLSは、対象となるテーブルに対して「ポリシー（Policy）」というルールをSQLで定義することで機能します。

例えば、「ユーザーは自分のデータだけを閲覧（SELECT）できる」というルールを作りたい場合、以下のような条件を書きます。

create policy "自分のデータのみ閲覧可能"
on "public"."posts"
for select
using ( auth.uid() = user_id );

ここでのポイントは auth.uid() = user_id という一行です。これは「現在ログインしているユーザーのID（auth.uid()）と、その行の user_id カラムの値が一致している場合のみ、アクセスを許可する」という意味になります。

このポリシーを一度設定してしまえば、フロントエンド側で「Aさんのデータだけを取得する」という複雑なコードを書かなくても、単に supabase.from('posts').select('*') とリクエストするだけで、自動的にAさんのデータだけが安全に抽出されます。

Supabaseを使った開発において、RLSは単なる「おまけのセキュリティ機能」ではなく、アーキテクチャの根幹を支える必須機能です。

最初はSQLでポリシーを書くことにハードルを感じるかもしれませんが、Supabaseのダッシュボードには豊富なテンプレートが用意されており、GUIからも直感的に設定が可能です。AIを活用してポリシーを生成するのも今の時代なら非常に簡単です。

フロントエンドとデータベースがシームレスに繋がる心地よい開発体験（Vibe Coding）を、RLSで安全に実現していきましょう！