Supabase と Firebase のアクセスルール（CWE-862）：Row Level Security の欠如がデータを露出させる仕組みと直し方

主要な概念と専門用語

公開の anon キー

Supabase の anon キーと Firebase の Web 設定はアプリのバンドルに含まれ、誰でもコピーできます。これらはユーザーではなくプロジェクトを識別するもので、秘密ではなく、それだけではデータを守れません。

Row Level Security（RLS）

すべてのクエリをポリシーで絞り込む PostgreSQL の機能です。Supabase の Table Editor は新しいテーブルで有効にしますが、SQL やマイグレーションで作ったテーブルは RLS がオフの状態で始まり、既定の権限により anon と authenticated がすべての行を読み書きできてしまいます。

USING と WITH CHECK

USING は、ユーザーが参照・更新・削除できる既存の行を決め、WITH CHECK は、書き込める新しい行や変更後の行を決めます。insert や update のポリシーに USING しかないと、別の組織の行を書き込めてしまいます。

service_role キー

service_role キーは RLS を完全に迂回します。サーバーやエッジ関数だけで使い、ブラウザやモバイルアプリには決して入れません。

Firestore のテストモードのルール

テストモードで始めたプロジェクトには、ある日付まですべての読み書きを許すルールが入り、その後 allow read, write: if true に書き換えられることもよくあります。ルールでは request.auth.uid をドキュメントの所有者フィールドと照合する必要があります。

ステップ・バイ・ステップの攻撃フロー

ソースコード比較：脆弱 vs 堅牢化

-- migration.sql: このテーブルでは RLS が一度も有効にされない
create table public.invoices (
  id bigint generated always as identity primary key,
  org_id uuid not null references public.orgs (id),
  customer text not null,
  amount_cents bigint not null
);

-- 公開の anon キーですべての行を読み、変更し、削除できる
grant select, insert, update, delete on public.invoices to anon, authenticated;

-- migration.sql: RLS を有効化、anon の権限を取り消し、コマンドごとにポリシー
create table public.invoices (
  id bigint generated always as identity primary key,
  org_id uuid not null references public.orgs (id),
  customer text not null,
  amount_cents bigint not null
);

-- RLS が有効なら、ポリシーがない操作はすべて拒否される
alter table public.invoices enable row level security;
revoke all on public.invoices from anon;

-- ユーザーは自分が所属する組織の請求書だけを見られる
create policy "members read their org's invoices"
  on public.invoices for select to authenticated
  using (org_id in (select org_id from public.memberships where user_id = (select auth.uid())));

-- 新しい行はユーザーの組織のものに限る。update と delete のポリシーはなし
create policy "members add invoices to their org"
  on public.invoices for insert to authenticated
  with check (org_id in (select org_id from public.memberships where user_id = (select auth.uid())));

エンジニアリング＆システム堅牢化チェックリスト

• 公開スキーマのすべてのテーブルで RLS を有効にし、select tablename from pg_tables where schemaname = 'public' and not rowsecurity が 1 行でも返したら CI を失敗させる。
• コマンドごとに to authenticated で限定したポリシーを書き、読み取りには USING、insert と update には WITH CHECK を使う。不要な update や delete のポリシーは作らない。
• 匿名ユーザーが読む理由のないテーブルでは anon の権限を取り消し、service_role キーはサーバー環境だけに置く。
• memberships のようにポリシーが参照するテーブルでも RLS を有効にし、ユーザーが自分を別の組織に追加できないようにする。
• 2 人のテストユーザーで確認し、ユーザー A がユーザー B の組織の行を 0 件しか取得できないことを確かめる。Firestore では @firebase/rules-unit-testing でエミュレーターに対してルールの単体テストを実行する。

参考資料

• CWE-862: Missing Authorization
• Supabase docs — Row Level Security
• PostgreSQL docs — CREATE POLICY
• Firebase docs — Get started with Cloud Firestore Security Rules
• NVD — CVE-2025-48757 (missing Row Level Security in generated apps)