- Создание 20 тысяч приложений с помощью вайб-кодинга
- Сканирование программ с помощью инструментов статического анализа
- Выявление типичных проблем вайб-кодинга с помощью ручного тестирования
- Повторное использование жестко закодированных распространенных секретов
- 50 самых популярных секретов
- GPT-5
- Claude Sonnet 4.5
- Gemini 2.5 Pro
- Почему распространенные секреты могут привести к уязвимостям
- Пример атаки: Подделка JWT-токена с помощью предполагаемого секрета
- Повторное использование учетных данных
- 10 наиболее распространенных вариантов учетных данных
- Повторное использование распространенных API-интерфейсов
- 20 наиболее распространенных API-интерфейсов
- Новые проверки безопасности в Invicti DAST на наличие распространенных уязвимостей, связанных с вайб-кодингом
- Вывод: безопасность улучшается, но LLM имеют свои недостатки
Все больше разработчиков используют большие языковые модели (LLM) для создания кода для веб-приложений. Для анализа насколько безопасны такие приложения, команда Invicti (на основе Acunetix и Netsparker) создала большое количество сайтов исключительно с помощью разных LLM, а затем исследовала их безопасность с помощью ручного и автоматизированного тестирования.
Создание 20 тысяч приложений с помощью вайб-кодинга
Были использованы разные модели LLM, как gpt-5, claude-sonnet-4.5, gemini-2.5-pro, deepseek-chat-v3-0324, qwen3-max и другие. Это также включает некоторые меньшие модели, такие как gpt-5-mini, gpt-oss-120b, gemini-2.5-flash.
Для создания веб-приложений был использован API OpenRouter, который обеспечивает легкий доступ к нескольким LLM через один прикладной программный интерфейс. Чтобы убедиться, что программы достаточно разнообразны, был использован широкий спектр подсказок.
- Применено много разных тем, фреймворков, технологий, требований и языков.
- Параметры менялись, чтобы получить разные результаты от LLM.
- Для архитектурного разнообразия некоторые программы это только REST/GraphQL API, другие являются полноценными приложениями с фронтендами и бекендами, некоторые монолитны, а другие базируются на микросервисах.
- Большинство приложений контейнеризированы с помощью Docker и Docker Compose.
В конце концов, удалось сгенерировать 20 656 веб-приложений. Ниже можно увидеть распределение программ, сгенерированных каждой моделью LLM:
Технологии, используемые в приложениях
Примеры сгенерированных приложений
ExpenseFlow: Трекер расходов, созданный с помощью claude-sonnet-4.5-604
Полнофункциональное приложение для отслеживания расходов, созданное с помощью Spring Boot, MySQL и Vue.js. Включает аутентификацию пользователей, административную панель, расширенные возможности поиска/фильтрации, документацию Swagger API и обратный прокси-сервер Nginx. Готовое к использованию контейнерное развертывание.
RestoOrder Pro: Приложение для онлайн-заказов, созданное с помощью gpt-5-511.
Готовое к работе веб-приложение для онлайн-заказов в ресторанах, созданное с помощью Express (Node.js), React, PostgreSQL и Nginx. Технологии: Node.js, Express, PostgreSQL, JWT Auth с RBAC, React (Vite), Swagger/OpenAPI, Docker, Docker Compose, Nginx.
Возможность скачать сгенерированные приложения для собственных исследований и тестирования
Веб-приложения, созданные для этого анализа, можно скачать с Hugging Face по этой ссылке: harisec/vibe-coded-web-apps.
Сканирование программ с помощью инструментов статического анализа
Все сгенерированные веб-приложения были просканированы с помощью нескольких инструментов статического анализа (SAST) и был составлен список наиболее распространенных уязвимостей, найденных в программах.
20 самых распространенных найденных уязвимостей
| Уязвимость | Частота | Количество приложений |
| Отсутствует ограничение частоты запросов | 7054 | 1039 |
| Утечка информации за исключением | 539 | 174 |
| Отображенный межсайтовый скриптинг на стороне сервера | 322 | 226 |
| Запрос в базу данных, построенный из источников, контролируемых пользователем | 242 | 87 |
| Использование сломанного или слабого криптографического алгоритма хеширования для конфиденциальных данных | 209 | 170 |
| Программа Flask работает в режиме дебага | 180 | 178 |
| Защита от CSRF не включена | 137 | 94 |
| Использование неконтролируемых данных в пути на ресурс | 81 | 62 |
| Защита от CSRF слабая или выключена | 74 | 57 |
| Запрос в базу данных, построенный из источников, контролируемых пользователем | 61 | 23 |
| Утечка информации через трассировку стека | 46 | 31 |
| Текст исключения, интерпретированный как HTML | 44 | 18 |
| Внедрение регулярного выражения (RegEx) | 27 | 16 |
| Включение функциональности из ненадежного источника | 22 | 17 |
| Хранение конфиденциальной информации в открытом тексте | 21 | 16 |
| Использование слабого хеша пароля | 19 | 12 |
| Неконтролируемые данные используются в выражении пути | 18 | 10 |
| SQL-запрос, построенный из источников, контролируемых пользователем | 17 | 13 |
| Логирование конфиденциальной информации в открытом тексте | 15 | 14 |
| Слабая конфигурация CORS | 15 | 15 |
Большинство из них это ложноположительные результаты, но часть уязвимостей все равно присутствует.
Общий уровень безопасности программ на основе вайб-кодинга
По сравнению с некоторыми старыми ИИ-помощниками, код, сгенерированный современными LLM, сейчас гораздо лучше с точки зрения безопасности, особенно в более крупных моделях. Было найдено гораздо меньше случаев SQL-инъекций, XSS, обхода пути и других распространенных уязвимостей, чем ожидалось.
Выявление типичных проблем вайб-кодинга с помощью ручного тестирования
После запуска автоматизированного сканирования, специалисты вручную просмотрели результаты. Затем был проведен полный ручной анализ небольшого подмножества сгенерированных веб-приложений (несколько десятков) и были найдены некоторые повторяющиеся проблемы безопасности, которые, кажется, типичны для приложений, созданных с помощью вайб-кодинга. Они в большинстве своем связаны с использованием жестко закодированных секретов, распространенных учетных данных и конечных точек.
Повторное использование жестко закодированных распространенных секретов
Было обнаружено, что многие веб-приложения используют жестко закодированные секреты для подписей JWT, ключей API, паролей базы данных и другой конфиденциальной информации. Интересно, что каждая модель LLM, кажется, имеет свой собственный набор распространенных секретов, которые она повторно использует в разных сгенерированных приложениях.
Причина этого заключается в том, что LLM учатся на коде, содержащем много примеров жестко закодированных секретов. При генерации нового кода LLM склонны повторно использовать эти секреты из своих обучающих данных, вместо того чтобы генерировать новые.
Как ни странно, supersecretkey используется несколькими LLM в нескольких сгенерированных приложениях. Было обнаружено, что из 20 тысяч проанализированных приложений 1182 где-то использовали такой ключ.
Вот самые распространенные секреты, найденные в сгенерированных веб-приложениях:
50 самых популярных секретов
| Значение секрета | Его частота |
| your-super-secret-jwt-key-change-in-production | 138 |
| your-super-secret-jwt-key | 23 |
| your-secret-key-here-change-in-production | 45 |
| your-secret-key-here | 163 |
| your-secret-key-change-in-production | 301 |
| your-secret-key-change-in-prod | 20 |
| your-secret-key | 178 |
| your-production-secret-key-change-this | 75 |
| your-production-secret-key | 16 |
| your_super_secret_jwt_key | 32 |
| your_secret_key_here | 139 |
| your_secret_key | 25 |
| your_jwt_secret_key_here | 74 |
| your_jwt_secret_key | 47 |
| your_jwt_secret_here | 67 |
| verysecretkey | 24 |
| supersecrettoken | 20 |
| supersecretkeyforjwt | 32 |
| supersecretkey123 | 43 |
| supersecretkey | 1182 |
| supersecretjwtkey | 235 |
| supersecretjwt | 69 |
| supersecretchangeme | 20 |
| supersecretchangeinprod | 20 |
| supersecret_jwt_key_change_me | 26 |
| supersecret_jwt_key | 27 |
| supersecret_change_me | 29 |
| supersecret | 570 |
| super-secret-key-change-in-production | 19 |
| super-secret-key | 179 |
| super-secret-jwt-key-change-in-production | 34 |
| super-secret-jwt-key | 72 |
| super-secret | 27 |
| super_secret_key | 34 |
| secretpassword | 46 |
| secretkey | 39 |
| secret123 | 211 |
| secret-token | 39 |
| secret_password | 24 |
| secret_key | 34 |
| secret | 661 |
| production-secret-key-change-me | 17 |
| mysecretpassword | 75 |
| mysecretkey | 211 |
| mysecret | 30 |
| my-secret-key | 18 |
| my_secret_key | 80 |
| my_jwt_secret_key | 23 |
| devsecret | 31 |
| change_this_secret | 46 |
Самые распространенные секреты для каждой из 3 лучших моделей LLM:
GPT-5
| Значение секрета | Его частота |
| supersecretjwt | 54 |
| secret123 | 30 |
| devsecret | 19 |
| supersecretjwtkey | 19 |
| dev_super_secret_change_me | 11 |
| supersecret_change_me | 11 |
| supersecret_jwt_key_change_me | 9 |
| dev_secret_change_me | 9 |
| supersecret | 7 |
| supersecretchangeme | 6 |
Claude Sonnet 4.5
| Значение секрета | Его частота |
| your-secret-key-change-in-production | 149 |
| change-this-secret-in-production | 12 |
| dev-secret-key-change-in-production | 12 |
| production-secret-key-change-me | 11 |
| super-secret-jwt-key-change-in-production | 9 |
| secret123 | 7 |
| docker-secret-key-change-in-production | 6 |
| change-this-secret-in-production-please | 6 |
| development-secret-key-change-in-production | 5 |
| jwt-secret | 5 |
Gemini 2.5 Pro
| Значение секрета | Его частота |
| a-very-secret-key-that-you-should-change | 11 |
| supersecretkey | 11 |
| a_very_secret_key_that_should_be_changed_in_production | 9 |
| a-very-secret-key-that-should-be-changed-in-production | 8 |
| secret123 | 8 |
| your-super-secret-key-that-is-long-and-secure | 8 |
| supersecret | 7 |
| a-very-strong-and-secret-key-for-jwt | 7 |
| a-very-secret-key-that-should-be-changed | 7 |
| your-super-secret-key-change-me |
Почему распространенные секреты могут привести к уязвимостям
Использование жестко закодированных секретов может привести к серьезным проблемам безопасности, таким как несанкционированный доступ, захват аккаунта, утечка данных и т.д.
JWT_SECRET установлен на supersecretjwt, что является наиболее распространенным секретом, используемым GPT-5. Очевидно, что такое значение может легко угадать злоумышленник.
Хотя это может показаться тривиальной проблемой, это может позволить злоумышленнику подделать JWT-токены и получить несанкционированный доступ к программе. Они могут даже создать JWT-токен с правами администратора и использовать его для доступа к защищенным конечным точкам. Ниже приведен пример, как это будет работать на практике.
Пример атаки: Подделка JWT-токена с помощью предполагаемого секрета
Важно: пример предоставлен исключительно для понимания рисков безопасности и того, как они могут реализоваться, и никак не побуждает к противоправным действиям.
Для программы, использующей JWT-токены, когда человек входит как обычный пользователь (не администратор), она получит ответ HTTP, который будет содержать токен. JWT-токен закодирован, но его можно декодировать с помощью любого инструмента декодирования JWT, такого как этот онлайн-декодер.
Чтобы подделать токен JWT с правами администратора, можно изменить поле роли из клиента на администратора. Однако, чтобы закодировать и подписать полезную нагрузку, которая предоставит злоумышленнику доступ администратора, нужно знать секретный ключ, используемый для его подписания. В этом случае это легко – он может догадаться, что это просто supersecretjwt.
Используя секретный ключ, можно подписать измененную полезную нагрузку и сгенерировать новый JWT-токен, используя тот же онлайн-инструмент, что и раньше, но в режиме кодировщика. Новый подписанный токен будет выглядеть так:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6Miwicm9sZSI6ImFkbWluIiwibmFtZSI6IlNhbXBsZSBVc2VyIiwiZW1haWwiOiJ1c2VyQGV4YW1wbGUuY29tIiwiaWF0IjoxNzYxODE0MTYzLCJleHAiOjE3NjI0MTg5NjN9.fTQz8A3zbiDRN8YWdbE9Asoo4w2lPiQtYEMQJEc8Rg8
Без подделанного токена был бы доступ только к конечным точкам клиента. Вот как выглядит приложение для клиента:
Рассматривая приложение, видно, что JWT-токен сохранен в локальном хранилище браузера:
Это означает, что можно просто заменить токен в локальном хранилище поддельным токеном, созданным ранее, и тогда будет получен доступ администратора к программе:
Повторное использование учетных данных
Веб-приложения, созданные с помощью вайб-кодинга, часто используют жестко закодированные общие учетные данные для входа и регистрации, такие как user@example.com:password123, admin@example.com:password, user@example.com:password и другие. Подобно проблеме распространенных секретов, каждая модель LLM, кажется, имеет свой набор учетных данных, которые она использует неоднократно в различных сгенерированных приложениях.
Использование таких учетных данных может быть даже хуже, чем жестко закодированные секреты, поскольку это может привести к захвату учетной записи, несанкционированному доступу и другим проблемам безопасности.
10 наиболее распространенных вариантов учетных данных
| Пароль | Его частота | |
| user@example.com | password123 | 110 |
| admin@example.com | password | 55 |
| user@example.com | password | 46 |
| john@example.com | password123 | 41 |
| john.doe@example.com | password123 | 22 |
| newuser@example.com | password123 | 19 |
| admin@example.com | admin123 | 18 |
| admin@example.com | password123 | 18 |
| user@example.com | secret123 | 14 |
| john@example.com | secret123 | 13 |
Повторное использование распространенных API-интерфейсов
Когда создается новая программа, она часто содержит распространенные API-интерфейсы входа и регистрации, такие как /api/login, /api/register, /auth/login, /auth/register, /login, /register и другие.
Хотя такие API-интерфейсы не всегда уязвимы, они становятся легкой мишенью для злоумышленников, которые могут злоупотреблять ими для регистрации новых аккаунтов, входа с помощью распространенных аккаунтов и исследования или использования других уязвимостей в программе.
20 наиболее распространенных API-интерфейсов
| /login | 5,446 |
| /auth/login | 5,343 |
| /swagger | 4,763 |
| /auth/register | 3,248 |
| /register | 2,735 |
| /api/auth/login | 1,366 |
| /swagger-ui | 1,022 |
| /health | 948 |
| /api/login | 888 |
| /items | 878 |
| /api/auth/register | 870 |
| /users | 868 |
| /docs | 641 |
| /admin/users | 633 |
| /api/register | 448 |
| /products | 434 |
| /logout | 421 |
| /token | 396 |
| /graphql | 391 |
Новые проверки безопасности в Invicti DAST на наличие распространенных уязвимостей, связанных с вайб-кодингом
В результате этого и других исследований Invicti Security создали и расширили несколько проверок безопасности в инструменте Invicti DAST, чтобы выявлять больше подобных уязвимостей.
- Invicti DAST теперь сканирует на наличие распространенных секретов, учетных данных и API-интерфейсов в веб-приложениях, сгенерированных с помощью вайб-кодинга.
- Каждый раз, когда сканер находит JWT-токен, проходит проверка, находится ли секрет, используемый для подписания токена, в списке распространенных секретов.
- Теперь Invicti также тестирует все конечные точки входа и регистрации со всеми учетными данными, часто встречающимися в таких веб-приложениях.
- Проверки безопасности включают сложные процессы, такие как попытка регистрации новой учетной записи, вход в новую учетную запись и проверка предсказуемости сгенерированного токена входа (JWT или другого).
Вот два примера уведомлений безопасности, которые Invicti может генерировать для этих уязвимостей:
Вывод: безопасность улучшается, но LLM имеют свои недостатки
Три года назад команда Invicti проанализировала безопасность кода сгенерированного GitHub Copilot, который был первым широко используемым помощником для написания кода на основе искусственного интеллекта. Этот анализ, проведенный Кадиром Арсланом, пришел к выводу: “Результаты моего исследования подтверждают предварительные выводы о том, что предложения часто вообще не учитывают безопасность”. И это был только помощник – тогда никто серьезно не предлагал создавать целое приложение, используя лишь искусственный интеллект.
Сегодня вайб-кодинг везде, и доступно много разных инструментов. Однако следует не забывать о безопасности. Это поможет Invicti DAST, и если вы хотите бесплатно протестировать эту платформу, оставьте ваши контактные данные ниже:
