Чеклист перед запуском приложения, написанного с ИИ
Восемь проверок до первых настоящих пользователей: секреты, доступ к данным, валидация, лимиты, бэкапы, алерты, вебхуки оплаты и окружения.
Приложение, собранное в Lovable, Bolt, Replit или Cursor, на демо обычно выглядит готовым. Кнопки нажимаются, данные сохраняются, оплата проходит. Проблемы начинаются, когда приходят люди, которые не знают, как «правильно» им пользоваться, и пара человек, которые знают, как неправильно.
Ниже — восемь пунктов, которые мы проверяем первыми. У каждого: что смотреть и по какому признаку понять, что сломано. Большинство проверок занимают минуты, исправления — от часа до пары дней.
Секреты в клиентском бандле
ИИ охотно кладёт ключ туда, где он сработает быстрее всего, — то есть в код, который уезжает в браузер. Всё, что попало в бандл, публично: открыть DevTools умеет любой.
Как проверить: собери продакшн-сборку и поищи по ней строки вроде sk_, secret, service_role, api_key. Посмотри вкладку Network: не ходит ли браузер напрямую в OpenAI, Stripe или в базу с ключом в заголовке.
Признак поломки: в клиенте есть хоть один ключ, который даёт больше, чем доступ на чтение публичных данных. Публичный ключ Supabase (anon) в клиенте — норма. Ключ service_role — нет, он обходит все правила доступа.
Проверки доступа на сервере
Самая частая дыра — данные защищены только интерфейсом. Кнопки «чужой заказ» нет, но запрос на /orders/123 с чужим номером отдаёт заказ. В Supabase это выглядит как таблица без Row Level Security или с политикой using (true).
Как проверить: заведи два аккаунта. Из-под первого создай запись, скопируй её идентификатор, войди вторым и запроси её напрямую — через curl или консоль браузера. Попробуй не только прочитать, но и изменить и удалить.
Признак поломки: хоть один из этих запросов прошёл. Отдельно проверь, включён ли RLS на каждой таблице, а не только на тех, о которых вспомнил.
Валидация входных данных
Форма не даёт ввести отрицательное количество, а API принимает. Поле «имя» ограничено 50 символами в интерфейсе и мегабайтом на сервере. Цена товара приходит из браузера, и сервер ей верит.
Как проверить: отправь запрос в обход формы — с пустыми полями, лишними полями, огромными строками, отрицательными числами, чужим user_id в теле.
Признак поломки: сервер сохраняет то, что форма бы не пропустила, или берёт из запроса то, что должен считать сам (цену, роль, владельца записи).
Лимиты частоты запросов
Без лимитов один скрипт может отправить тысячу писем со сброса пароля, перебрать коды из SMS или сжечь месячный бюджет на ИИ за ночь.
Как проверить: отправь сотню одинаковых запросов на вход, регистрацию, отправку кода и любой эндпоинт, который вызывает платный API.
Признак поломки: все сто прошли. Лимиты нужны хотя бы на адрес и на аккаунт, и на дорогие операции — строже, чем на остальное.
Бэкапы и учения по восстановлению
Бэкап, из которого ни разу не восстанавливались, — это надежда, а не бэкап. Восстановление обычно ломается на мелочах: нет прав, не та версия, файлы лежат отдельно от базы.
Как проверить: возьми последний бэкап и подними из него копию в отдельном окружении. Засеки время. Проверь, что там есть свежие данные и загруженные файлы.
Признак поломки: ты не знаешь, где лежит бэкап, сколько он хранится, или восстановление не получилось с первого раза. Лучше узнать это в спокойный вторник.
Логи и алерты об ошибках
Если об ошибках ты узнаёшь от пользователей, ты узнаёшь о малой их части: большинство просто уходит.
Как проверить: специально сломай что-нибудь на стейджинге — брось исключение в обработчике — и посмотри, придёт ли уведомление и сколько времени это займёт.
Признак поломки: уведомления нет, или оно тонет в сотне других, или в логе нет ничего, по чему можно понять, какой пользователь и какой запрос. Заодно проверь обратное: не пишутся ли в лог пароли, токены и полные номера карт.
Идемпотентность вебхуков оплаты
Платёжные системы присылают вебхуки повторно, иногда не по порядку, иногда с задержкой. Если на каждый вебхук ты начисляешь подписку или кредиты, повтор начислит их второй раз.
Как проверить: отправь один и тот же вебхук дважды (у Stripe и подобных есть тестовые инструменты для этого). Проверь подпись: прими вебхук с неверной подписью — должен быть отказ.
Признак поломки: двойное начисление или успешная обработка без проверки подписи. Минимальная защита — хранить идентификатор события и не обрабатывать его повторно:
create unique index on payment_events (provider_event_id);
Разделение окружений
Тестовые заказы в боевой базе, письма реальным людям со стейджинга, один ключ API на всё — классика проекта, выросшего из одного окружения.
Как проверить: у разработки, стейджинга и продакшна должны быть разные базы, разные ключи платёжной системы (тестовые и боевые), разные почтовые настройки. Посмотри, откуда приложение берёт конфигурацию и что будет, если запустить его локально.
Признак поломки: локальный запуск пишет в боевую базу или может отправить настоящее письмо и провести настоящий платёж.
Что дальше
Этот список не делает приложение безопасным, он убирает самые дешёвые способы его сломать. Если хотя бы три пункта у тебя отмечены как «сломано», запуск стоит сдвинуть на неделю — это дешевле, чем разбирать последствия.
SUBXCAT проходит этот список вместе с командой, чинит найденное и оставляет проверки, которые не дают ему сломаться снова.