Безопасность Supabase: как проверить RLS и доступ к данным

Как браузер получает доступ к данным

Браузер обращается к Data API проекта. Ключ определяет приложение, пользовательская сессия — личность, grants — доступ к операции, RLS — доступные строки. Это несколько уровней проверки, и они не заменяют друг друга. Скрытая таблица в интерфейсе не становится закрытой в базе. Схема ниже помогает определить, где именно принято решение, прежде чем менять SQL ради исчезновения ошибки.

Какие ключи публичные а какие секретные

Publishable предназначен для публичного клиента, secret — для доверенной серверной среды. Legacy anon и service_role имеют разные полномочия; service_role нельзя помещать в клиентскую сборку. Строка, похожая на JWT, не автоматически является секретом: определите назначение ключа по своему проекту. Сервер с повышенными полномочиями обязан самостоятельно проверять права пользователя перед запросом к данным.

Первичные источники: Supabase: RLS · Supabase: типы ключей

Продолжить: IDOR и BOLA: как проверить доступ к чужим данным в своём API

Как описать правила своей таблицы

Для учебной notes используем личного владельца owner_id. Запишите ожидания для SELECT, INSERT, UPDATE и DELETE отдельно: A читает и меняет свою заметку, B — свою, анонимный запрос не получает приватных строк. Командный доступ потребует дополнительной модели членства; простая проверка owner_id для него недостаточна. До создания новой политики проверьте существующие политики и grants, чтобы не оставить параллельный широкий доступ.

Минимальная политика чтения

Скачиваемая SQL-фикстура проверяет механизм RLS на изолированной PostgreSQL-базе с тестовой функцией личности. Это локальная проверка семантики политик, а не подключение к вашему облачному Supabase. Для использования в Supabase применяйте штатную auth.uid(), реальные роли и миграцию своего проекта. Тестовый владелец таблицы не должен подменять обычного пользователя при проверке: привилегированные контексты могут обходить ограничения.

alter table public.documents enable row level security;
create policy "owner reads" on public.documents
for select to authenticated
using (owner_id = (select auth.uid()));
-- Отдельные политики требуются для INSERT / UPDATE / DELETE.
-- UPDATE: USING проверяет старую строку, WITH CHECK — новую.

Первичные источники: Supabase: RLS · Supabase: типы ключей

Продолжить: Утечка .env .git или API-ключа: как закрыть доступ и проверить исправление

Как проверить запись и изменение владельца

USING определяет строки, с которыми можно работать; WITH CHECK проверяет допустимость результирующей строки при соответствующей операции. Не разрешайте A вставлять заметку от имени B или менять owner_id на B. На стенде сравните состояние до и после отказа. Сообщение new row violates row-level security policy может быть правильным результатом запрета, а не поводом отключить RLS.

Матрица из двух пользователей

Проверьте минимум шесть случаев: анонимное чтение, A→A, A→B, вставку owner_id=B от A, смену владельца и разрешённое изменение B→B. Для SELECT недоступная строка может просто отсутствовать в результате. Поэтому пустой список нужно сопоставлять с работающим контролем владельца. Матрица ниже даёт ожидаемые наблюдения, но не заменяет ваши правила общего доступа.

Первичные источники: Supabase: RLS · Supabase: типы ключей

Продолжить: Безопасность Next.js: проверка API Server Actions и секретов

Что проверить рядом с таблицами

Storage, views, функции и серверные маршруты с повышенными правами требуют самостоятельной проверки. Политика одной таблицы не доказывает защиту файлов или результата функции. Проверьте, какие контексты выполняют запрос и какие поля возвращаются клиенту. Scantelio может наблюдать настроенные HTTP-сценарии, но не получает административный обзор всех политик Supabase из публичного URL.

Как перенести исправление и повторить

Сохраните исправление как миграцию, проверьте её на staging и повторите поведенческий тест после релиза. Владелец должен сохранять разрешённые действия. Если опубликован секрет с повышенными полномочиями, одной правки RLS недостаточно: ограничьте и отзовите этот доступ по процедуре провайдера. Для автоматического ретеста подготовьте обычные тестовые личности, известные объекты и ожидаемые права.

Продолжить: Проверка безопасности API с тестовыми аккаунтами

Воспроизводимые примеры и материалы

Проверено: guides-1 · PostgreSQL RLS (локальный стенд)

Учебные данные — синтетические. Файлы не содержат действующих ключей или клиентской базы. Запускайте примеры только в собственной изолированной тестовой среде.

• Самопроверяемый SQL-стенд: роли, RLS, проверки и откат
• rls-matrix.csv — редактируемый шаблон

Протокол проверки примера: версии, действия и наблюдения

Вопросы и ответы

Автор и источники

Редакция Scantelio: методика и границы проверки. Проверка примера: 2026-11-02.

• Supabase: RLS
• Supabase: типы ключей