Уязвимости вайб-кода: как AI-сгенерированные сайты открывают дыры для хакеров

Вайб-кодинг дал миллионам людей возможность создавать приложения без знания программирования — достаточно описать задачу на обычном языке, и ИИ сгенерирует рабочий код. Это удобно, быстро и часто даёт отличный результат. Но за этой доступностью скрывается проблема, о которой большинство новичков просто не думают: ИИ пишет рабочий код — но не всегда безопасный.

История одного сайта

Боб Старр, проект-менеджер из технологической отрасли, использовал вайб-кодинг для создания сайта «Boomberg» — инструмента, который наглядно показывал, сколько налоговых денег США уходит технологическим компаниям. Результатом он остался доволен и сразу запустил проект в открытый доступ — именно так и работает вайб-кодинг: быстро, от идеи к продукту, без промежуточных этапов. Только спустя несколько месяцев Старр обнаружил тревожную деталь: в коде присутствовала SQL-инъекция. Это классическая уязвимость, при которой злоумышленник может читать или изменять данные в базе, просто сформулировав специальный запрос. Уязвимость существовала с самого запуска — просто никто её не заметил.

«Это было явное упущение с моей стороны.

Полное слепое пятно при освоении новой технологии. И я уверен, что другие совершают ту же ошибку», — признал Старр в разговоре с The Verge.

Почему ИИ пропускает угрозы ИИ-инструменты для кодинга оптимизированы

для одного: чтобы код делал то, что от него просят. Они генерируют функциональный результат быстро — но безопасность нередко уходит на второй план или вовсе игнорируется. Проблема не в качестве генерации.

Проблема в том, что пользователь без опыта в разработке не знает, какие вопросы задавать. Опытный инженер после написания кода обязательно проверит: как данные попадают в запросы к базе, кто имеет доступ к административным функциям, не попали ли секреты в репозиторий. Для большинства вайб-кодеров такие вопросы просто не возникают.

Типичные уязвимости в вайб-кодированных проектах: SQL-инъекции — код не очищает пользовательский ввод перед передачей в базу Открытые API-ключи — секреты попадают прямо в исходный код Устаревшие зависимости — использование библиотек с известными уязвимостями Незащищённые эндпоинты — административные функции без проверки авторизации * XSS-уязвимости — небезопасный вывод данных в браузере ## Масштаб не стоит недооценивать Вайб-кодинг давно вышел за рамки нишевого явления. Cursor, GitHub Copilot, Replit и Lovable привлекли десятки миллионов пользователей, многие из которых создают код впервые в жизни. Часть таких проектов — личные эксперименты без реальных пользователей.

Но другая часть уже работает в интернете, обрабатывает реальные данные и открыта для любого желающего. Важно понимать: уязвимость, которую нашёл Старр, — не экзотическая. SQL-инъекции входят в список OWASP Top 10 уже больше 15 лет и остаются одной из самых распространённых проблем веб-приложений.

ИИ воспроизводит их потому, что обучался на коде, который их содержал. История Боба Старра показательна именно тем, что он не пытался срезать углы — он просто не знал, что именно нужно проверить. И в этом главный структурный риск вайб-кодинга: не злой умысел, а системное незнание.

Что это значит

Вайб-кодинг снижает порог входа в разработку, но не снимает ответственности за то, что ты выпускаешь в сеть. Если проект обрабатывает данные пользователей или просто доступен из интернета — базовый аудит безопасности обязателен. Попросить того же ИИ проверить код на уязвимости, изучить OWASP Top 10 или отдать проект на беглый аудит специалисту — уже хорошее начало.