Защита активов: Как 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.