Начните с карты входов, а не с названия продукта
Возьмём учебный пример: небольшой сервис создаёт документы, принимает оплату и присылает результат в Telegram. У него есть страница, API генерации, файловое хранилище, платёжный webhook и обработчик команд бота. Это вымышленный сценарий, а не рассказ о взломанном клиенте. Главная страница может работать идеально, пока один из остальных входов разрешает лишнее.
Запишите рядом с каждым входом три вещи: кто имеет право обратиться, что он может изменить и какие расходы вызывает операция. У входа может быть отдельный домен или только путь. Исходящий вызов API нейросети тоже важен для бюджета, хотя посетитель напрямую к нему не подключается.
| Часть проекта | Вопрос перед запуском | Где проверять |
|---|---|---|
| Кабинет и API | Видит ли пользователь только разрешённые документы? | Серверные проверки прав и два тестовых аккаунта. |
| Генерация, SMS, загрузки | Что остановит серию дорогих операций? | Квоты приложения, ограничения запроса и бюджет провайдера. |
| Telegram-бот | Как подтверждается отправитель и право выполнить команду? | Обработчик бота, webhook и Mini App, если они есть. |
| Оплата | Кто подтверждает сумму и выдаёт доступ? | Серверная интеграция с платёжным сервисом. |
| Репозиторий и сборка | Не получил ли посетитель серверный ключ? | История изменений, итоговые файлы и настройки публикации. |
Что меняет разработка с ИИ
Вайбкодинг ускоряет переход от идеи к работающему экрану. Но запрос «сделай авторизацию» не задаёт все права на документы, админские операции и команды бота. После очередного изменения полезно проверять именно нарушенный сценарий: например, доступ к чужому файлу после добавления общего поиска.
Не делайте вывод о безопасности по происхождению кода. Ручной код тоже бывает уязвимым, а приложение, написанное с ИИ, может пройти полноценную проверку. Нужны наблюдаемые результаты: разрешённое действие выполняется, запрещённое отклоняется, деньги и данные остаются в ожидаемом состоянии. OWASP ASVS помогает выбрать требования для такой приёмки; это не автоматический сертификат безопасности.
Подробнее в первоисточнике: OWASP ASVS: требования к проверке безопасности приложения.
Проверьте чужие данные прежде, чем улучшать экран входа
В учебном сервисе пользователь А создал документ, пользователь Б вошёл в свой аккаунт. Успешный вход Б подтверждает его личность, но не даёт права читать документ А. Проверка владельца нужна на сервере при чтении, изменении, удалении и скачивании. Случайный UUID сам по себе не заменяет решение о доступе. OWASP описывает этот класс ошибок как Broken Object Level Authorization, или BOLA.
Для своей тестовой среды составьте короткую матрицу: гость, владелец, другой пользователь, администратор. Для каждого действия укажите ожидаемый результат. Если чужой документ оказался доступен, сначала исправьте проверку прав и закройте конкретный путь. Добавление заголовка безопасности или фильтра трафика не восстановит отсутствующую проверку владельца.
Подробнее в первоисточнике: OWASP API1: доступ к чужим объектам.
Защитите деньги, токены и платные операции
Определите, где проект тратит деньги без участия владельца: запрос модели, отправка SMS, обработка файла, аренда вычислений. В нашем примере ограничение на одну генерацию в интерфейсе бесполезно, если сервер принимает любое количество новых заданий. Учитывайте одновременно операции конкретного пользователя, общий бюджет и незавершённые задания.
Отдельно проверьте, откуда берётся цена заказа и кто подтверждает оплату. Перенаправление покупателя на страницу «успешно» не должно само выдавать доступ. Серверный ключ платёжного сервиса или бота не должен попасть в скачиваемый JavaScript, пример конфигурации или публичный отчёт агента.
- Запишите, какая операция считается оплачиваемой, и как предотвращается её повторное выполнение.
- Поставьте уведомление о расходе там, где он возникает; ограничение на входе приложения не заменяет контроль счёта поставщика.
- Проверьте отзыв тестового ключа: старое значение должно перестать работать, а сервис — перейти на новое.
Подробнее в первоисточнике: OWASP API4: расход ресурсов и платных интеграций; OWASP: хранение, права и жизненный цикл секретов.
Где помогает защита трафика
RoboGuard размещается на пути HTTP-запросов к подключённому домену. WAF проверяет поддерживаемые признаки вредных запросов, ограничения помогают сдерживать нежелательную нагрузку, а антибот — управлять автоматическими обращениями. Приложение остаётся на вашем сервере. Для API и webhook правила подбираются под машинные запросы: браузерную проверку нельзя бездумно требовать от платёжного сервиса или Telegram.
Этот слой полезен после запуска и во время исправлений, но границы должны быть понятны. RoboGuard не исправляет права в базе, не отзывает украденный токен и не проверяет код бота. Прямые обращения к стороннему хранилищу, Telegram Bot API или открытому origin обходят защиту подключённого домена. Сетевую атаку на канал нужно разбирать с провайдером.
| Задача | Что должно работать вместе |
|---|---|
| Сдержать поток к публичному API | Правила HTTP-трафика и ограничения операций внутри приложения. |
| Закрыть доступ к чужим данным | Проверка прав на сервере и регрессионный тест; WAF её не заменяет. |
| Принимать уведомления об оплате | Подлинность события, сверка заказа, защита от повторов и доступность webhook. |
| Сохранить работоспособность после настройки | Проверка входа, API, оплаты и нужной автоматизации через новый маршрут. |
Практический порядок действий
Выделите один законченный пользовательский путь: зарегистрироваться, создать объект, оплатить, получить результат. Затем для каждого шага проверьте неправильного пользователя, повтор запроса и отказ внешней системы. Так список замечаний превращается в задачи с проверяемым результатом, а не в абстрактный балл риска.
Бесплатная проверка RoboGuard показывает доступность публичной страницы, HTTPS и часть настроек ответа. Она не подтверждает отсутствие BOLA, утечек ключей или ошибок оплаты. Используйте её как внешний старт, а статьи ниже — для проверки приложения и подготовки подключения трафика.
- Составьте карту доменов, API, webhook, хранилищ и платных действий.
- Уберите раскрытые секреты через отзыв и замену; закройте подтверждённый посторонний доступ.
- Пройдите проверки прав, платежей и повторных операций в тестовой среде.
- Настройте HTTP-защиту на подходящих доменах и проверьте штатные запросы.
- Сохраните результаты приёмки и повторяйте затронутые проверки после изменения сценария.
Вопросы и ответы
Любой вайбкод-проект обязательно уязвим?
Нет. Способ написания кода не доказывает уязвимость. Проверять нужно конкретные права, настройки и операции; подтвердить проблему можно воспроизводимым результатом.
Если у меня только API или Telegram-бот, защита нужна?
Проверьте доступные входы и последствия операций. Публичный HTTP API или webhook можно направить через совместимую защиту трафика. Для бота только с long polling такого входа может не быть; ему всё равно нужны безопасные команды, ключи и ограничения расходов.