Перед первыми пользователями проверьте пять вещей: не попали ли секретные ключи в браузерный код или репозиторий; видит ли пользователь только свои данные, если подменить идентификатор в запросе; включены ли правила доступа на уровне базы (например, RLS в Supabase); есть ли резервная копия, из которой вы умеете восстановиться; и кому принадлежат аккаунты, домен и код. Эти проверки не делают приложение неуязвимым, но закрывают ошибки, последствия которых трудно исправить после запуска.
Содержание
- Почему рабочий прототип ещё не готов к реальным людям
- Ключи и секреты: всё, что в браузере, — публично
- Доступ к данным: видит ли пользователь только своё
- Деньги и лимиты: что может прийти в счёте
- Данные, резервные копии и изменения схемы
- Владение: аккаунты, код и возможность уйти с платформы
- Чек-лист перед запуском и что делать дальше
Почему рабочий прототип ещё не готов к реальным людям
Если вы собрали продукт с Cursor, Claude Code, Lovable, Bolt или Replit — это настоящее достижение: идея превратилась в работающее приложение, которое можно показать клиентам и инвесторам. То, что часто называют вайбкодингом, отлично подходит для проверки гипотез. Вопрос в другом: прототип и продукт для реальных людей решают разные задачи.
AI-ассистент делает то, что вы описали: сценарий, который работает на демо. Он не знает, что один из ваших будущих пользователей откроет инструменты разработчика в браузере, подменит номер заказа в запросе или отправит тысячу запросов к платной функции. Если об этом не спросить явно, такие сценарии остаются непроверенными — не из-за «плохого ИИ», а потому что их не было в задаче.
Демо
- Один пользователь — вы
- Тестовые данные, которые не жалко
- Ошибку можно исправить и показать ещё раз
- Деньги не двигаются
Реальные пользователи
- Много людей, и некоторые любопытны
- Чужие персональные данные и ваша ответственность за них
- Утечку нельзя «откатить»
- Платежи, платные API и счета провайдеров
Ключи и секреты: всё, что в браузере, — публично
Код, который выполняется в браузере, может прочитать любой посетитель. Сборщики прямо об этом предупреждают: в Vite переменные с префиксом VITE_ попадают в клиентский код при сборке и не должны содержать API-ключи; в Next.js переменные с префиксом NEXT_PUBLIC_ встраиваются в JavaScript, который получает браузер. Если ключ к платному или привилегированному сервису оказался в такой переменной, он фактически опубликован.
Не все ключи секретны. У Supabase — базы, которую подключают в том числе AI-конструкторы, — есть публикуемый ключ (publishable, раньше anon) — он предназначен для браузера, и его безопасность держится на правилах доступа к строкам базы. И есть секретный ключ (secret, раньше service_role): он обходит все правила Row Level Security, и документация прямо запрещает класть его в браузер, в приложение или в систему контроля версий. Ключи LLM-провайдеров, платёжных сервисов, SMS-шлюзов — только на сервере.
Поиск в собранном сайте
Откройте приложение, инструменты разработчика → вкладки Sources и Network, и поищите по словам
secret,service_role,sk-,api_key.Поиск в репозитории и его истории
Ключ, который удалили последним коммитом, остаётся в истории. GitHub secret scanning проверяет всю историю веток; для приватных репозиториев организаций он доступен в платных планах.
Проверка
.gitignoreФайлы
.envс реальными значениями не должны попадать в репозиторий.Ротация, а не удаление
Если ключ утёк, его нужно перевыпустить у провайдера. Переписывать историю Git после отзыва ключа обычно уже не обязательно.
Доступ к данным: видит ли пользователь только своё
Первая позиция в OWASP API Security Top 10 (редакция 2023 года) — Broken Object Level Authorization: сервер принимает идентификатор объекта, но не проверяет, имеет ли этот пользователь право на этот объект. На практике это выглядит так: в адресе или запросе стоит order_id=1042, пользователь меняет его на 1043 и видит чужой заказ. Пятая позиция — Broken Function Level Authorization: обычный пользователь вызывает функцию, предназначенную администратору, потому что кнопку спрятали в интерфейсе, а проверку на сервере не сделали.
Если данные лежат в Supabase или другой PostgreSQL-базе, к которой браузер обращается напрямую, защитой служат политики Row Level Security. Документация Supabase формулирует правило жёстко: включайте RLS на каждой таблице в открытой схеме; таблица без RLS доступна на чтение и запись любой роли, у которой есть права на неё. Таблица с включённым RLS и без единой политики через публикуемый ключ недоступна вовсе — это безопасное состояние по умолчанию.
Два тестовых аккаунта
Создайте пользователей A и B. Пользователь A создаёт запись — заказ, заметку, документ.
Подмена идентификатора
Войдите как B и попробуйте открыть, изменить и удалить запись A по её идентификатору — через адрес страницы и через запрос во вкладке Network.
Чужие функции
Обычным пользователем вызовите действия администратора: смену роли, удаление, выгрузку.
Без входа
Повторите запросы без авторизации. Ожидаемый ответ — отказ, а не пустой успешный ответ и не данные.
Проверка RLS
В панели базы убедитесь, что RLS включён на всех таблицах с пользовательскими данными, и прочитайте каждую политику: кому и что она разрешает.
Деньги и лимиты: что может прийти в счёте
OWASP отдельно выделяет неограниченное потребление ресурсов: каждый запрос тратит процессор, память и трафик, а некоторые вызывают платные сервисы — SMS, проверки, языковые модели. Если функция «сгенерировать ответ» доступна без ограничений, один скрипт может создать вам счёт у провайдера и заодно положить сервис для остальных пользователей.
- У каждого платного провайдера (LLM, SMS, карты, хостинг) настроены лимиты расходов или уведомления о превышении.
- Эндпоинты, которые вызывают платные API, требуют входа и ограничены по частоте на пользователя.
- Размер входных данных ограничен: длина текста, размер файла, число элементов в запросе.
- Факт оплаты подтверждает сервер по уведомлению платёжного провайдера, а не браузер по возврату со страницы оплаты.
- Регистрация и формы защищены от массовой автоматической отправки.
Данные, резервные копии и изменения схемы
Резервная копия, из которой никто не пробовал восстановиться, — это надежда, а не план. Проверьте, что копии делаются автоматически, хранятся отдельно от основной базы, и хотя бы раз восстановите копию в отдельное окружение. Запишите, сколько это заняло и какие шаги понадобились.
- Тестовая и рабочая базы разделены: AI-ассистент экспериментирует на тестовой.
- Изменения структуры базы оформлены миграциями в репозитории, а не сделаны кликами в консоли рабочей базы — иначе их нельзя повторить и откатить.
- Собираются только те персональные данные, без которых сценарий не работает, и известно, где они хранятся.
- Ошибки на сервере попадают в журнал или сервис мониторинга, и вы узнаёте о сбое раньше пользователей.
Владение: аккаунты, код и возможность уйти с платформы
Быстрые конструкторы удобны тем, что берут на себя хостинг и базу. Обратная сторона — продукт может оказаться привязан к аккаунту одного человека или к платформе, с которой его трудно перенести. Это нужно знать до того, как на продукте появятся клиенты.
- Аккаунты конструктора, базы, хостинга и домена оформлены на корпоративную почту, включена двухфакторная аутентификация.
- Код синхронизирован с репозиторием Git, который принадлежит вашей компании.
- Продукт можно собрать и запустить вне платформы по инструкции из репозитория — или вы знаете, что нельзя, и это осознанное решение.
- Есть список всех подключённых сервисов и ключей с указанием, где каждый хранится.
- Профессиональная команда, если вы её подключите, сможет получить доступ без передачи ваших личных паролей.
Чек-лист перед запуском и что делать дальше
- В браузерном коде и истории репозитория нет секретных ключей; утёкшие — перевыпущены.
- Пользователь B не может прочитать, изменить или удалить данные пользователя A.
- Функции администратора проверяют роль на сервере.
- RLS включён на всех таблицах с пользовательскими данными, политики прочитаны.
- Платные API ограничены по частоте, у провайдеров настроены лимиты расходов.
- Оплата подтверждается сервером.
- Восстановление из резервной копии проверено.
- Тестовая и рабочая среды разделены, схема меняется миграциями.
- Аккаунты, домен и репозиторий принадлежат компании.
Если большинство пунктов выполнено, следующий разумный шаг — разбор именно тех модулей, где ошибка дороже всего: доступы и роли, данные, платежи, сборка и выкатка. Итогом такого разбора должна быть карта рисков и решение по каждому модулю — оставить, исправить или заменить, — а не предложение переписать всё.
