Внешне всё выглядит готовым: логин, форма, дашборд, база данных. Но именно этот готовый интерфейс может быть обманчив. Приложение может работать и при этом раскрывать конфиденциальные данные.
В этом заключается центральный риск Vibe-кодинга: разработка программного обеспечения перемещается из редактора в чат, пользователи описывают, что они хотят создать, а ИИ-системы генерируют на основе этого код, модели данных и инструкции по развертыванию. В современных бэкенд-сервисах, таких как Supabase, это во многом зависит от ролей, прав доступа к таблицам и политик безопасности на уровне строк (Row Level Security). Таким образом, в центр внимания выходит невидимый защитный слой, скрытый за интерфейсом.
RLS как невидимый защитный слой
Supabase, бэкенд-сервис на основе PostgreSQL, лежит в основе расследования издания Zeit (Paywall)(открывается в новом окне), для которого Zeit сотрудничал с экспертом по ИТ-безопасности Кристофером Хельмом. Согласно расследованию, Хельм сузил круг поиска, используя общедоступные технические признаки использования Supabase. Затем он проверил выборку из 670 немецкоязычных веб-сайтов.
Результат: почти в каждой второй базе данных был возможен доступ. Найденное содержимое варьировалось от медицинских данных до паролей, документов для подачи заявлений, клиентских данных и технических чертежей.
С технической точки зрения речь идет прежде всего о Row Level Security (RLS). Supabase в своей документации(открывается в новом окне) указывает, что RLS должна быть всегда включена для таблиц в открытой схеме. Для таблиц, созданных через Table Editor, это действует автоматически.
Тем, кто создает таблицы с помощью SQL или других инструментов, необходимо самостоятельно устанавливать защитный слой и соответствующим образом ограничивать роли. Таким образом, техническая причина кроется не только в отдельной неверной конфигурации, но и во взаимодействии прав доступа к таблицам, ролей и политик RLS.
От находки к матрице
Согласно имеющимся документам, Хельм не ограничился отдельными находками. Он создал частный рабочий репозиторий, который, по его словам, был адресован Полу Копплстоуну, генеральному директору и сооснователю Supabase, а также директору по информационной безопасности Биллу Хармеру.
В нем Хельм описывает «Supabase security audit skill» и каталогизирует 61 возможный вектор. Речь идет не о подтвержденных единичных случаях, а о проверяемых шаблонах: небезопасные настройки по умолчанию, повторяющиеся ошибки операторов, ловушки в коде приложения и новые поверхности для атак, например, связанные с Realtime, pg_net, Vault, ограничениями скорости или резервным копированием.
Это разграничение очень важно. Репозиторий не является ни списком конкретных утечек данных, ни обобщенным отчетом об уязвимостях, направленным против Supabase. Будет ли затронут тот или иной проект, должна показать только проверка на соответствующей целевой системе.
Таким образом, расследование превращается в нечто большее, чем просто сборник отдельных неверных конфигураций. Оно описывает повторяющийся шаблон риска: проекты, созданные с помощью ИИ, могут генерировать работающие приложения, но при этом перенимают допущения в области безопасности, которые не работают в продуктивной среде. Поэтому главный вопрос заключается не только в том, кто пишет код, но и в том, кто проверяет архитектуру безопасности.
Эта ролевая проблема особенно коварна для ИИ-агентов. Они часто создают не только интерфейсы, но и файлы миграций, схемы баз данных и вспомогательные функции. Если модель создает таблицу и забывает о соответствующей политике доступа, ошибка не обязательно выглядит как ошибка. Приложение загружается, формы сохраняют данные, тестовые аккаунты работают. Только взгляд со стороны показывает, что бэкенд превратился в общедоступный канал данных.
Это отличает такие пробелы от многих классических ошибок программирования. Отдельная команда может допустить опечатку, но генератор кода может внедрить один и тот же шаблон во множество проектов. Соответствующая запись в Github в проекте Supabase показывает, что вопрос безопасных настроек по умолчанию обсуждается уже давно. Здесь очевидно противостояние удобства и безопасности.
Безопасность — это не переключатель
Golem спросил Кристофера Хельма, какие минимальные проверки безопасности необходимы перед запуском приложения на Supabase. Его ответ — это скорее критика принципов, чем контрольный список.
Хельм предостерегает от понимания безопасности как бинарного состояния. При достаточном творческом подходе и времени почти всегда можно найти уязвимости — независимо от того, создан ли проект с помощью Vibe-кодинга, агентного инжиниринга или классической разработки. Поэтому решающим фактором является понимание собственных слабых мест и поверхностей для атак. Только тогда можно осмысленно работать над снижением рисков.
По словам Хельма, Supabase уже усилил меры. Теперь сервис автоматически распознает некоторые потенциальные риски безопасности и более четко отображает возможные пробелы в панели управления. Такие предупреждения могут сделать неверные конфигурации более заметными. Однако они не заменяют понимания безопасности. Тот, кто обрабатывает реальные пользовательские данные, должен по-прежнему проверять, какие таблицы, роли, политики и ключи доступны в продуктивной среде.
```