Проверка безопасности после вайбкодинга: чек-лист до запуска
Начните с того, что будет дороже всего раскрыть или изменить: клиентские документы, платные функции и действия администратора. Для каждого риска назначьте владельца проверки и укажите, какой результат остановит выпуск.
Что подготовить
Составьте короткую карту: публичный URL, вход пользователя, приватный объект, действие с последствиями и внешние сервисы. Отметьте версию и среду. Не используйте реальные платёжные реквизиты и действующие секреты как тестовые маркеры.
Порядок проверки
Сначала проверьте то, что доступно извне
В браузере без входа изучите публичный маршрут и клиентскую сборку на своём стенде. Проверьте, что служебный файл не отдаёт секреты, а действие администратора блокируется на сервере. Обычная публичная конфигурация и секретный ключ — разные вещи.
Пройдите один платный или приватный сценарий целиком
Два тестовых клиента создают по записи. Проверьте чтение своей записи, отказ чужому, скачивание и один разрешённый сценарий после правки. Для зависимостей сравните версии именно опубликованного артефакта с применимыми бюллетенями.
Фрагмент решения перед первым запуском
Блокер: другой клиент видит вымышленный приватный документ.
Неполно: WAF не пустил ни владельца, ни второго пользователя.
Повторить: тот же маршрут и обе роли на сборке с исправлением.Критерий результата и ограничения
К релизу приложите список пройденных сценариев, известных пропусков и человека, который принимает остаточный риск. Скачиваемый чек-лист можно заполнить вместе с разработчиком.
Что остаётся непроверенным
Пустой автоматический отчёт не означает готовность к запуску. Для требований оплаты, персональных данных и внешних интеграций нужны отдельные проверки по вашему продукту.