Supabase RLS: почему данные пользователей видны всем и как закрыть
Если в Supabase данные пользователей видны всем, почти всегда причина одна — политики доступа на уровне строк (RLS) не включены или настроены неправильно. По умолчанию таблица в PostgreSQL отдаёт все строки любому, кто подключился с правильным ключом, если явно не ограничить доступ. Закрывается это включением RLS и написанием политик под конкретные роли и условия.
Коротко
- Чаще всего причина — RLS не включён или политики написаны неправильно.
- Проверить можно за несколько минут: запросом с публичным ключом без авторизации.
- Чинится настройкой политик под конкретные роли, а не отключением доступа вообще.
- После исправления стоит повторно проверить доступ тем же способом.
- Это часть более широкого аудита безопасности, а не разовая настройка одной галочки.
Что это и когда возникает
RLS, Row Level Security — это политики доступа на уровне строк таблицы в PostgreSQL, на котором работает Supabase. ИИ-инструменты вайб-кодинга часто создают таблицы и подключение к ним, но не включают и не настраивают RLS по умолчанию — потому что это требует понимания, какие роли должны видеть какие строки, а это бизнес-логика, а не шаблонный код.
Варианты: уровни защиты
| Уровень | Что это даёт | Для кого подходит |
|---|---|---|
| RLS отключён | Любой с ключом видит все данные | Не подходит никому с реальными пользователями |
| RLS включён без политик | Доступ закрыт полностью, даже легитимным запросам | Временное состояние на время настройки |
| RLS с политиками по ролям | Каждый видит только своё, админ — видит больше | Рабочее состояние для продакшена |
| RLS с политиками + аудит логов | То же самое плюс видимость, кто и что запрашивал | Для проектов с повышенными требованиями к данным |
Сколько стоит и из чего складывается цена
Диагностика — бесплатно: проверяю доступ к данным через публичный ключ и смотрю, какие таблицы затронуты. Если нужно только настроить политики на уже понятной структуре данных — это почасовая работа от 3 000 ₽/час. Если требуется более широкий аудит безопасности (секреты, авторизация, зависимости) — обычно это заказ под ключ от 50 000 ₽.
Что ломается в эксплуатации
Если политики написаны слишком узко, легитимные запросы начинают получать пустые ответы, и это выглядит как «сломался сайт», а не как проблема безопасности — важно тестировать политики на реальных сценариях использования, а не только на факте их наличия.
Когда это не нужно
Если в таблице нет персональных или чувствительных данных и доступ к ней публичный по замыслу (например, список статей блога) — закрывать её политиками RLS не обязательно, достаточно убедиться, что это осознанное решение, а не упущение.
Что спросить у подрядчика
- Как вы проверяете, что доступ закрыт — какой конкретный запрос делаете?
- Политики пишутся под каждую таблицу отдельно или есть общий шаблон?
- Что будет с уже написанным кодом фронтенда после включения RLS?
- Это входит в разовую починку или требует отдельного сопровождения?
- Дадите ли отчёт о том, что было проверено и исправлено?
Как это сделано у меня
Проверка RLS — часть аудита безопасности, который я делаю для проектов на ИИ. Подробнее о составе и цене — на странице ВайбФикс.
Частые вопросы
Как понять, что RLS не настроен?
Проще всего — попробовать запросить данные через публичный API-ключ (anon key) без авторизации. Если в ответе приходят чужие строки — политики не работают.
Включение RLS сломает уже работающий сайт?
Сразу после включения RLS без политик доступ закрывается полностью, то есть сайт может перестать получать данные. Поэтому политики пишутся и проверяются вместе с включением, а не отдельно.
Это одна настройка на весь проект или нужно делать для каждой таблицы?
Для каждой таблицы отдельно — RLS включается и настраивается на уровне таблицы, и для каждой нужны свои условия доступа.
Ещё по теме
Разработчик. Пишу о починке проектов на ИИ и ИИ-автоматизации на основе своей практики. Подробнее — как я работаю.
Если Telegram не открывается: MAX · oongemakh@gmail.com
Обновлено: