Вайбкодинг безопасность данные утечка Supabase — это не абстрактный страх, а вполне бытовая ошибка: ИИ собирает приложение, а таблица или файлы остаются доступными не тому пользователю. Проверять нужно не только код, но и RLS, Storage, ключи, функции и логи. Я, Арина Михална, собрала порядок аудита, который можно пройти до публикации проекта.
Почему вайбкодинг открывает базу
Вайбкодингу легко простить кривую кнопку. Утечке данных он не прощает ничего.
Когда ты просишь ИИ: «Сделай личный кабинет с профилем пользователя», модель обычно создаёт таблицу, запросы и интерфейс. Но фраза «пользователь видит только свои данные» должна превратиться в реальное ограничение на уровне базы. Если она осталась только в JavaScript, любой человек может отправить запрос напрямую к API.
Типичный сценарий выглядит так:
- В таблице
profilesлежат имена, почта и служебные поля. - Frontend запрашивает данные по
user_id. - В интерфейсе показывается профиль текущего пользователя.
- В базе нет политики, которая запрещает прочитать чужую строку.
- Запрос с другим идентификатором возвращает чужой профиль.
Внешне приложение работает. Кнопки красивые. Демо можно показать заказчику. А защита отсутствует.
В материале TechCrunch от 25 сентября 2026 года описана проблема с проектами Supabase, которые публично открывали большие объёмы пользовательских данных. Это ровно тот класс ошибок, который появляется не из-за «злого ИИ», а из-за разрыва между сгенерированным интерфейсом и правилами доступа в базе.
Вайбкодинг ускоряет сборку. Поэтому он же ускоряет размножение одной ошибки по нескольким таблицам. Перед тем как отдавать агенту доступ к проекту, полезно разобраться, что такое скиллы Claude: скилл можно настроить на повторяемый аудит, но финальное решение всё равно остаётся за человеком.
Интерфейс уже собран, но теперь нужно увидеть, где он может открыть лишнее.
В канале «А.М. решает вопросы» я разбираю такие рабочие ситуации и показываю, как проверять ИИ-результат руками:
зайти в канал и забрать разборыВайбкодинг безопасность данные утечка Supabase: что проверять
Начни не с чтения всего проекта, а с карты данных. Выпиши таблицы, бакеты и функции, к которым обращается приложение.
| Зона | Как ломается | Что должно быть |
|---|---|---|
| Таблицы | RLS выключен или политика разрешает всем select |
RLS включён, доступ ограничен ролью и владельцем записи |
| Политики | Условия проверяют только факт входа | Учитываются auth.uid(), роль и связь с объектом |
| Storage | Бакет публичный, URL угадывается или живёт слишком долго | Файлы закрыты, доступ выдаётся по правилу |
| Frontend | В код попал секретный ключ или service role | В браузере нет серверных секретов |
| RPC и функции | Пользователь вызывает функцию с чужим id |
Внутри функции есть проверка прав, а не доверие к параметрам |
1. Таблицы и RLS
RLS, или Row Level Security, ограничивает доступ к строкам на уровне PostgreSQL. Включить его мало. Нужны политики для конкретных действий: чтения, добавления, изменения и удаления.
Проверь каждую таблицу вопросами:
- может ли анонимный посетитель сделать
select; - видит ли авторизованный пользователь чужие строки;
- может ли пользователь изменить
user_idу своей записи; - разрешено ли удалить данные другого человека;
- что произойдёт, если в запросе подставить чужой идентификатор.
Особенно опасны политики вроде «разрешить всё авторизованным». Авторизация говорит только, что человек вошёл. Она не говорит, что ему принадлежат все строки таблицы.
Хорошая проверка выглядит скучно: создай два тестовых аккаунта, добавь по записи от каждого и попробуй прочитать, изменить и удалить чужую запись. Скучно — значит полезно.
2. Storage и публичные ссылки
В Storage часто утекают не таблицы, а документы: аватары, договоры, сканы, выгрузки и фотографии клиентов.
Публичный бакет удобен для картинок сайта. Для персональных файлов он превращается в открытую полку. Если ссылка на файл доступна без проверки пользователя, RLS таблиц уже не спасёт.
Проверь:
- какие бакеты публичные;
- можно ли открыть файл в режиме инкогнито;
- может ли пользователь заменить чужой объект;
- проверяется ли владелец папки;
- не лежат ли документы рядом с публичными изображениями;
- не возвращает ли API список файлов соседнего пользователя.
Supabase отдельно описывает контроль доступа для Storage, и этот раздел стоит проходить руками, а не просить агента «настроить безопасность». Агент может написать политику. Он не знает, какой именно файл нельзя показать клиенту.
Как провести аудит за один проход
Сделай отдельный тестовый проект или хотя бы тестовые записи. Не экспериментируй на production, когда проверяешь удаление и изменение данных.
Шаг 1. Собери инвентаризацию
Попроси Claude составить таблицу:
Проанализируй обезличенную схему проекта.
Для каждой таблицы укажи:
1. какие данные в ней лежат;
2. кто должен читать, создавать, изменять и удалять строки;
3. какое поле связывает строку с пользователем;
4. какие риски есть при анонимном запросе;
5. какие тесты нужно выполнить.
Не придумывай отсутствующие политики. Отдельно помечай
неизвестные места.В промпт не вставляй реальные токены, дампы базы, почты клиентов и содержимое документов. Для анализа достаточно схемы, имён полей и обезличенных примеров.
Шаг 2. Проверь роли
Минимум нужны три сценария:
- анонимный посетитель;
- пользователь А;
- пользователь Б.
Для каждого сценария проверь чтение, создание, изменение и удаление. Если в проекте есть администратор, добавь четвёртую роль, но не превращай её в универсальный ключ от всех дверей.
Шаг 3. Посмотри запросы напрямую
Не ограничивайся интерфейсом. Открой Network в браузере и посмотри, какие запросы уходят в Supabase. Затем повтори их с изменённым идентификатором.
Проверяй не только успешный экран. Ошибка тоже должна быть безопасной: она не должна возвращать лишние поля, внутренние идентификаторы и технические подробности.
Шаг 4. Проверь секреты
В репозитории и настройках проекта не должны лежать:
- service role key;
- секреты сторонних API;
- пароли к базе;
- ключи webhook;
- приватные переменные окружения, собранные в frontend.
Публичный ключ клиента не следует считать защитой. Он виден браузеру, поэтому вся реальная граница безопасности должна находиться в базе, Storage и серверных функциях.
Шаг 5. Проверь логи
В логах ищи:
- всплеск чтения одной таблицы;
- запросы к данным с большим диапазоном идентификаторов;
- массовые ошибки доступа;
- обращения к Storage от неизвестных сценариев;
- вызовы функций, которых не делает интерфейс.
Лог не покажет всё, что случилось в мире, но поможет понять масштаб и время проблемы. Включи привычку смотреть его после крупных изменений, особенно когда ИИ переписал несколько политик за один запрос.
Что делать после обнаружения утечки
Паника здесь бесполезна. Нужна последовательность.
- Закрой дыру. Отключи ошибочную политику, закрой бакет или убери опасную функцию из публичного доступа.
- Отзови секреты. Замени серверные ключи и токены, которые могли попасть в frontend, логи или репозиторий.
- Сохрани следы. Зафиксируй время, URL, настройки политик и фрагменты логов до изменений, если это можно сделать без дальнейшего раскрытия данных.
- Оцени объём. Установи, какие таблицы и файлы были доступны, кому и как долго.
- Проверь копии. Ищи ключи в истории Git, CI-логах, сборках и старых deploy-артефактах.
- Разбери последствия. Если затронуты персональные данные, подключи специалиста по требованиям к обработке и уведомлению о таких инцидентах.
Нельзя считать проблему решённой только потому, что сейчас URL возвращает ошибку. Файл могли скачать раньше, а секрет мог попасть в кэш, историю репозитория или чужой лог.
Про безопасность агентов я отдельно показывала пример с ограничением прав в статье как ограничить права AI-агента. Логика та же: агенту и пользователю дают минимальные права, а опасные действия требуют отдельной проверки.
После утечки важно не только закрыть дверь, но и понять, как она открывалась.
В канале есть разборы сноса аккаунтов и ошибок при работе с ИИ, включая практические причины и порядок действий:
перейти к материалам Арины Михалны
Как работать с ИИ без передачи лишних данных
ИИ полезен для аудита, если дать ему задачу правильно. Просьба «сделай безопасно» слишком расплывчатая. Нужны границы и проверяемый результат.
Передавай агенту:
- схему таблиц без реальных значений;
- список ролей;
- ожидаемые права каждой роли;
- обезличенные политики;
- тестовые сценарии;
- требования к ошибкам и логированию.
Проси на выходе не красивый отчёт, а конкретные артефакты:
- список возможных уязвимостей;
- таблицу «роль → действие → ресурс»;
- SQL-проверки;
- негативные тесты;
- перечень неизвестных мест;
- diff для политики, который ты можешь прочитать.
Потом прогоняй тесты отдельно от агента. Claude может заметить, что политика слишком широкая. Но если ты попросил его же написать и подтвердить собственный код, получится не аудит, а автограф.
Я, Арина Михална, в таких задачах держу простое правило: ИИ предлагает гипотезу, а доступ проверяется отдельным пользователем. Это занимает больше времени, зато не оставляет безопасность на уровне «модель сказала, что всё хорошо».
По материалам: TechCrunch о публичном раскрытии данных в проектах Supabase, документация Supabase по Row Level Security, документация Supabase по контролю доступа к Storage.
Читайте также
- ИИ-агенты риски безопасности тестирование: что происходит в 2026
- Slack Code и вайбкодинг: совместная разработка
- Как ограничить ИИ-агента, чтобы он не хакнул сайт вместо вас: чек-лист безопасности
- На портале «Мастерская нейросетей»: Безопасность ИИ-агентов для бизнеса в 2026: как не потерять контроль
Если хочешь получать такие разборы и готовые схемы проверок, заходи в Telegram-канал «А.М. решает вопросы»: там я показываю, как находить опасные места в проектах с ИИ до того, как их найдёт кто-то другой — подписаться на канал.
