RLS（Row Level Security）

なぜ学ぶか： このカリキュラムで最も重要なセキュリティトピックのひとつ。anonキーが公開できる理由、そして「AIが作ったSupabaseアプリで他人のデータが丸見え」という実際に多発している事故を防ぐ仕組みがRLS。「テーブルを作ったらRLS」を合言葉にできれば、このフェーズは合格です。

RLS＝行ごとのアクセス制御

「この行を読める/書けるのは誰か」を行単位で定めるルール。アプリではなくDB自身が門番になります。

anonキー公開の根拠はこれ

キーは「入口の場所」しか教えません。何ができるかはRLSが決める — だからキーが見えても、許された行しか触れません。

定番ルール：auth.uid() = user_id

「行のuser_idが、今ログインしている本人なら許可」— 自分のデータだけ触れる、最頻出のルールです。

RLS無しの公開＝データ全公開

anonキーは公開前提なので、RLSの無いテーブルは世界中から読み書きできます。AIはテーブル作成時にRLSを忘れることがあり、人間が必ず確認します。

SQLの例

-- 進捗テーブル（この学習アプリの本実装でも使う設計）
create table progress (
  id uuid primary key default gen_random_uuid(),
  user_id uuid references auth.users(id) not null,
  topic_id text not null
);

-- 1. 門を閉める（RLS 有効化）
alter table progress enable row level security;

-- 2. 通れる条件を書く（自分の行だけ読める）
create policy "自分の進捗だけ読める"
  on progress for select
  using (auth.uid() = user_id);

-- 書き込みは別のルールで許可する（操作ごとにルールを分けられる）
create policy "自分の進捗だけ追加できる"
  on progress for insert
  with check (auth.uid() = user_id);

auth.uid()は「今ログインしている本人のid」。RLSを有効にすると、ルールの無い操作はすべて拒否されます。だから「読む用（select）」「書く用（insert）」のように操作ごとにルールを書きます。このlearnアプリの進捗同期（将来実装）も、この設計で守ります。

ステップ 1 / 2

← カリキュラム一覧へ戻る

※ カリキュラムの内容はAIが生成しており、誤りが含まれる場合があります。正確な情報は公式ドキュメント等でご確認ください。