Защита активов: Как RLS спасает бизнес от уязвимостей ИИ-кода

Критический риск: почему AI-генераторы кода пропускают Row-Level Security#

Row-Level Security (RLS) в PostgreSQL — это главный эшелон защиты конфиденциальных данных вашей компании при разработке на Supabase. По умолчанию создаваемые таблицы могут быть полностью открыты для чтения и записи анонимными пользователями через публичный PostgREST API.

Пошаговый протокол полной изоляции базы данных#

Выполните эти обязательные команды для всех публичных таблиц в вашей продакшен-базе Supabase:

-- Шаг 1: Активация RLS на всех таблицах
ALTER TABLE public.profiles ENABLE ROW LEVEL SECURITY;
ALTER TABLE public.domains ENABLE ROW LEVEL SECURITY;
ALTER TABLE public.domain_tasks ENABLE ROW LEVEL SECURITY;

-- Шаг 2: Политика безопасного чтения только своих данных
CREATE POLICY "Пользователи читают только свой профиль"
  ON public.profiles
  FOR SELECT
  USING (auth.uid() = id);

-- Шаг 3: Политика безопасного обновления только своего профиля
CREATE POLICY "Пользователи обновляют только свой профиль"
  ON public.profiles
  FOR UPDATE
  USING (auth.uid() = id)
  WITH CHECK (auth.uid() = id);

Защита от эскалации привилегий и рекурсии#

1. 1
   **Используйте SECURITY INVOKER по умолчанию**: функции выполняются с правами вызывающего пользователя и соблюдают все ограничения RLS.
2. 2
   **Задавайте явный SET search_path = public для SECURITY DEFINER**: при создании триггеров на регистрацию пользователя обязательно фиксируйте search path для предотвращения атак типа search-path injection.
3. 3
   Исключите рекурсию в политиках: никогда не делайте SELECT из таблицы profiles внутри RLS-проверки на profiles. Используйте отдельную SQL-функцию is_admin() с флагом SECURITY DEFINER.