Правила доступа в Supabase и Firebase (CWE-862): как отсутствие Row Level Security раскрывает данные и как это исправить

Ключевые понятия и термины

Публичный ключ anon

Ключ anon Supabase и веб-конфигурация Firebase поставляются внутри пакета приложения, и любой может их скопировать. Они определяют проект, а не пользователя, поэтому не являются секретом и сами по себе данные не защищают.

Row Level Security (RLS)

Функция PostgreSQL, которая пропускает каждый запрос через политики. Table Editor в Supabase включает её для новых таблиц, но таблицы, созданные через SQL или миграции, начинают с выключенной RLS, и права по умолчанию позволяют anon и authenticated читать и менять любую строку.

USING и WITH CHECK

USING определяет, какие существующие строки пользователь может видеть, изменять или удалять; WITH CHECK — какие новые или изменённые строки он может записать. Политика только с USING для insert или update позволяет записывать строки для чужой организации.

Ключ service_role

Ключ service_role полностью обходит RLS. Ему место только на серверах и в edge-функциях, но никогда не в браузере или мобильном приложении.

Правила 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 на каждой таблице в открытых схемах и проваливайте CI, если select tablename from pg_tables where schemaname = 'public' and not rowsecurity возвращает хотя бы одну строку.
• Пишите по одной политике на команду с ограничением to authenticated: USING для чтения и WITH CHECK для insert и update; не добавляйте ненужные политики update и delete.
• Отзовите права на таблицу у anon, если анонимным пользователям незачем её читать, и храните ключ service_role только в серверных окружениях.
• Включите RLS и на таблицах, которые читают ваши политики, например memberships, чтобы пользователи не могли добавить себя в чужую организацию.
• Проверяйте на двух тестовых пользователях: пользователь A должен получать ноль строк по организации пользователя B; для 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)