Открытая база
и ключи в коде

§1Как нейросеть оставляет базу открытой

Сервисы вроде Supabase и Firebase дают готовую базу данных, вход пользователей и хранилище файлов без собственного сервера. Страница сайта обращается к базе напрямую из браузера. Для этого в код страницы встраиваются адрес проекта и публичный ключ. Публичный ключ виден любому, кто откроет инструменты разработчика, и это предусмотрено устройством сервиса: доступ к данным должны ограничивать правила на стороне базы.

В Supabase такие правила называются RLS (Row Level Security, защита на уровне строк): для каждой таблицы задаётся, какие строки может читать и менять пользователь. Если RLS для таблицы выключен, публичного ключа достаточно, чтобы прочитать её целиком. В Firebase ту же роль играют правила безопасности (Security Rules). Нейросеть при генерации проекта часто выключает правила или оставляет разрешение «всем», потому что с ними первая версия не работает, а без них страница сразу показывает данные.

Масштаб показывает исследование компании UpGuard, опубликованное 25 сентября 2026 года (TechCrunch, BleepingComputer): 16 326 баз Supabase, таблицы которых можно было прочитать через интерфейс доступа к данным. Больше чем в половине из них, судя по названиям таблиц, хранились персональные данные: имена, адреса, телефоны, пароли, токены входа. Адрес проекта и ключ исследователи брали из открытого JavaScript-кода сайтов.

§2Кто отвечает за ошибку нейросети

Нейросеть, Supabase и GitHub не являются операторами персональных данных вашего проекта. Оператор — тот, кто определяет, зачем и какие данные собираются.

152-ФЗ «О персональных данных»ст. 3, п. 2ред. от 26.07.2026

2) оператор - государственный орган, муниципальный орган, юридическое или физическое лицо, самостоятельно или совместно с другими лицами организующие и (или) осуществляющие обработку персональных данных, а также определяющие цели обработки персональных данных, состав персональных данных, подлежащих обработке, действия (операции), совершаемые с персональными данными;

Для «КурсБлиновской» оператором данных своих клиентов — школ и авторов — является ООО «КурсБлиновской», а данных учеников — школы, которые поручили платформе их хранить (глава 3.1). Обязанность защищать данные лежит на операторе и не зависит от того, кто написал код: работник, подрядчик или нейросеть.

152-ФЗ «О персональных данных»ст. 19, ч. 1ред. от 26.07.2026

1. Оператор при обработке персональных данных обязан принимать необходимые правовые, организационные и технические меры или обеспечивать их принятие для защиты персональных данных от неправомерного или случайного доступа к ним, уничтожения, изменения, блокирования, копирования, предоставления, распространения персональных данных, а также от иных неправомерных действий в отношении персональных данных.

Таблица без правил доступа — это отсутствие технической меры от неправомерного доступа. Кроме того, Supabase и Firebase по умолчанию размещают базы за рубежом. Если в такую базу первыми записываются данные граждан России, нарушена ещё и локализация (глава 3.4), а это отдельный штраф до 6 млн ₽.

§3Открытая база — это уже утечка

Обязанность уведомить Роскомнадзор возникает не только при краже базы. Закон перечисляет передачу, предоставление, распространение и доступ.

152-ФЗ «О персональных данных»ст. 21, ч. 3.1ред. от 26.07.2026

3.1. В случае установления факта неправомерной или случайной передачи (предоставления, распространения, доступа) персональных данных, повлекшей нарушение прав субъектов персональных данных, оператор обязан с момента выявления такого инцидента оператором, уполномоченным органом по защите прав субъектов персональных данных или иным заинтересованным лицом уведомить уполномоченный орган по защите прав субъектов персональных данных:
1) в течение двадцати четырех часов о произошедшем инциденте […];
2) в течение семидесяти двух часов о результатах внутреннего расследования выявленного инцидента […].

Когда открытую таблицу находит исследователь, журналист или пользователь, для оператора начинается отсчёт 24 часов. Чтобы понять, был ли посторонний доступ, смотрят журналы запросов к базе: в Supabase они есть в разделе Logs. Если в журналах видны запросы к таблице с чужих адресов или журналы не сохранились, исходят из того, что доступ был.

Для небольшого проекта с базой меньше тысячи человек части 12–14 не применяются, но остаются обязанность уведомить и штраф за неуведомление по ч. 11. Посторонний, который сознательно выгрузил открытую таблицу с персональными данными, отвечает сам: использование и хранение незаконно полученных данных — ст. 272.1 УК. То, что таблица была открыта, не делает выгрузку законной.

§4Разбор: таблица учеников без RLS

§5Проверка перед запуском

Три проверки занимают несколько минут и закрывают большую часть типовых дыр. Их запускают до первого пользователя и после каждой крупной генерации кода.

select tablename
from pg_tables
where schemaname = 'public' and rowsecurity = false;

Запрос выполняется в SQL-редакторе Supabase. Каждая таблица в ответе читается публичным ключом. Для неё включают RLS и пишут политику: например, ученик видит только свои заявки, а школа — заявки на свои курсы.

curl "https://PROJECT.supabase.co/rest/v1/students?select=*&limit=1" \
  -H "apikey: ПУБЛИЧНЫЙ_КЛЮЧ"

Ответ [] или ошибка доступа означает, что таблица закрыта. Если в ответе строка с данными — её увидит любой. Запрос отправляют только к своему проекту: проверка чужой базы без разрешения владельца — неправомерный доступ (глава 9.1).

gitleaks detect --source . --log-opts="--all"
grep -rnE "service_role|sk-[A-Za-z0-9]{20,}|BEGIN PRIVATE KEY" dist/ build/ .next/ 2>/dev/null

Первая команда ищет ключи во всей истории коммитов: удалить файл в новом коммите недостаточно, ключ остаётся в истории. Найденный ключ считают скомпрометированным и выпускают новый у поставщика. Вторая команда проверяет собранные файлы сайта, которые получает браузер: служебного ключа в них быть не должно.