Пройти путь от идеи до работающего приложения за несколько дней сегодня обычное дело. Прототип, собранный в Cursor, Claude Code, Lovable или Bolt, может выглядеть безупречно на демо. Проблема в том, что расстояние между «работает на демо» и «можно открывать реальным пользователям» невидимо.
В этой статье мы пытаемся сделать это расстояние измеримым: что говорят исследования о коде, созданном ИИ, какие уязвимости встречаются чаще всего и какие проверки нужно провести до запуска.
Работающий код и безопасный код не одно и то же
Языковые модели отлично пишут код, который выполняет запрошенное поведение. Но выполнить запрос и гарантировать, что им нельзя злоупотребить, это разные задачи. Попросите «страницу профиля пользователя», и модель её сделает. Вопрос «что будет, если другой пользователь поменяет ID в URL?» она обычно не задаёт, пока его не зададите вы.
Природа vibe coding это усиливает. Когда код принимается без построчного чтения, решения по безопасности просто не принимаются. Приложение работает, потому что единственный проверенный сценарий это добросовестный пользователь.
Что говорят исследования
Здесь уже не догадки, а измерения. Выделяются два исследования.
Veracode 2025 GenAI Code Security Report протестировал более 100 языковых моделей на задачах, чувствительных к безопасности, на Java, JavaScript, Python и C#. 45% сгенерированных образцов кода содержали уязвимость из OWASP Top 10. В задачах на cross-site scripting (XSS) доля неудач достигла 86%.
Отчёт CodeRabbit за 2025 год рассмотрел реальные pull request: 320 PR с участием ИИ против 150 PR, написанных только людьми. В PR с ИИ в среднем было 10,83 проблемы, в человеческих 6,45. По категориям разница ещё заметнее:
| Тип уязвимости | В коде с участием ИИ |
|---|---|
| Cross-site scripting (XSS) | в 2,74 раза чаще |
| Небезопасная прямая ссылка на объект (IDOR) | в 1,91 раза чаще |
| Неправильная обработка паролей | в 1,88 раза чаще |
Здесь важна честность: часто повторяемая фраза «в коде ИИ в 2,74 раза больше уязвимостей» на самом деле относится только к категории XSS. Общая картина не «всё в три раза хуже». Но в отдельных типах уязвимостей есть явная системная тенденция, и это именно те типы, которые обходятся дороже всего в продакшене.
Чек-лист из 8 пунктов перед запуском
Этот список состоит из того, на что мы смотрим в первую очередь, когда берём проект, быстро собранный с помощью ИИ. Всё это можно проверить за аудит длиной в несколько дней.
1. Не утекли ли секреты в код или на клиент?
API-ключи, строки подключения к базе и учётные данные сервисных аккаунтов это самая частая проблема. Особенно ключи во фронтенд-коде: их может прочитать любой в браузере. Проверьте и историю git: удалённый ключ продолжает жить в истории коммитов.
2. Проверяется ли авторизация на сервере при каждом запросе?
Аутентификация (кто ты) и авторизация (к чему у тебя есть доступ) это разные вещи. Скрыть кнопку в интерфейсе не значит авторизовать. На каждом API-эндпоинте проверяйте на сервере, что запрошенная запись принадлежит этому пользователю. Уязвимости IDOR возникают именно из-за этого пробела.
3. Открыты ли правила доступа к базе данных?
В проектах на Supabase и Firebase клиент общается с базой напрямую. Тогда единственная линия защиты это правила безопасности на уровне строк (RLS в Supabase). Таблица без правил открыта любому, у кого есть анонимный ключ.
4. Валидируется и экранируется ли пользовательский ввод?
Считайте недоверенными любые данные из форм, URL или API. Валидируйте схемы на сервере, избегайте рендеринга сырого HTML, используйте параметры в запросах к базе.
5. Реальны ли зависимости и актуальны ли они?
Модели иногда предлагают несуществующие имена пакетов. Злоумышленники могут зарегистрировать эти имена и поместить внутрь вредоносный код; такую атаку называют «slopsquatting». Убедитесь, что каждая новая зависимость действительно нужный пакет, и запускайте автоматическое сканирование известных уязвимостей.
6. Есть ли ограничение частоты запросов и защита от злоупотреблений?
Вход, регистрация, сброс пароля и особенно эндпоинты, вызывающие языковую модель, не должны быть открыты без rate limit. Иначе за одну ночь можно получить и попытки захвата аккаунтов, и неожиданный счёт за API.
7. Не говорят ли сообщения об ошибках и логи слишком много?
В продакшене пользователю не должны возвращаться stack trace, ошибки SQL или внутренние пути к файлам. В логах не должно быть паролей, токенов и персональных данных.
8. Разделены ли среды разработки и продакшена?
Отдельная база, отдельные ключи, резервные копии и план отката. Частый сценарий в vibe code проектах: база, использованная при разработке, переносится в продакшен как есть.
Одного чек-листа недостаточно
Эти пункты ловят самые частые проблемы, но не заменяют аудит безопасности. Больший риск в коде, который никто по-настоящему не понимает. Когда находится уязвимость, тот, кто её исправляет, должен понимать, как работает система. Подробно мы разбирали это в статье о долге знаний.
И ещё: писать код с ИИ не проблема. Большинство команд уже пользуются этими инструментами, и выигрыш в скорости реален. Проблема в том, что скорость производства обгоняет скорость проверки. Решение не в замедлении, а в том, чтобы сделать проверку частью процесса: добавить статический анализ и сканирование зависимостей в CI и сделать код-ревью обязательным для критичных эндпоинтов.
Заключение
Vibe coding это самый быстрый способ получить прототип за дни. Но прежде чем он станет продуктом с реальными данными пользователей, работающий код нужно превратить в безопасный. Восемь пунктов выше это отправная точка.
Аудит, укрепление безопасности и запуск проектов, созданных с ИИ, мы выполняем в рамках услуги Vibe Code to Production. О настройке автоматического сканирования и конвейеров развёртывания читайте на странице DevOps и CI/CD.
