TL;DR
Каждое второе задеплоенное приложение, созданное через Claude Code или Lovable, содержит критические уязвимости — не потому что AI плохой программист, а потому что у него есть три системных сбоя: он забывает про безопасность по мере написания кода, оптимизирует каждый кусок локально не думая о целом, и не знает специфики вашей архитектуры. Это не баги конкретных моделей — это паттерны, воспроизводящиеся во всех популярных инструментах.
Главная находка: вайб-кодинг порождает уникальные классы дыр, которых нет в обычном коде — "заглушечная логика" (AI пишет авторизацию, которая пропускает всех), незафильтрованный ввод пользователя и секреты прямо во фронтенде. Это не ошибки из учебника — это новые паттерны, специфичные именно для AI-разработки.
Хорошая новость: лёгкие техники промптинга оказались эффективнее сложных агентных систем. Два добавления к промпту — просьба писать "в продакшн" и просьба проверить себя — дают максимальное снижение уязвимостей. Это работает прямо в чате, без дополнительных инструментов.
Схема метода
Это не пошаговый алгоритм — это два инструмента, которые добавляются к любому промпту вайб-кодинга:
ИНСТРУМЕНТ 1 — "Production request"
Добавь в начало промпта: требование production-ready кода
→ AI переключает режим с "работает на моей машине" на "работает в реальном мире"
ИНСТРУМЕНТ 2 — "Self-check request"
Добавь в конец промпта: попроси AI проверить своё решение на безопасность
→ AI находит часть собственных дыр до того как ты запустил код
ОБА ИНСТРУМЕНТА в одном промпте → максимальный эффект
Оба работают в одном сообщении. Отдельных запросов не нужно.
Пример применения
Задача: Ты делаешь через Claude Code простой сервис — например, форму записи клиентов для своей студии / агентства / магазина. Нужна авторизация, приём данных от пользователей, сохранение в базу.
Промпт:
Создай production-ready веб-приложение для записи клиентов студии растяжки.
Функционал:
- Форма записи: имя, телефон, выбор времени из слотов
- Админ-панель для просмотра записей (только для владельца)
- Уведомление на email при новой записи
Требования к качеству:
- Код должен быть готов к реальному деплою, не демо-версия
- Все входящие данные от пользователей — валидируй и очищай
- Авторизация в админ-панели — настоящая, не заглушка
- Секреты (API ключи, пароли) — только в переменных окружения, не в коде
- После того как напишешь — сделай самопроверку: пройдись по OWASP Top 10
и проверь своё решение на каждый пункт. Исправь найденные проблемы.
Результат:
AI сгенерирует приложение, потом явно выполнит самопроверку по пунктам — ты увидишь список: "Проверил инъекции — ОК, проверил авторизацию — нашёл проблему, исправил вот так..." Финальный код будет существенно безопаснее, чем тот же запрос без этих двух добавлений. Заглушечная логика в авторизации и открытые API-ключи — два самых частых дефекта — будут устранены с высокой вероятностью.
Почему это работает
Три сбоя, которые объясняют всё. AI-агент при вайб-кодинге работает в длинном диалоге. К моменту написания авторизации он "забыл" требования безопасности из начала сессии (memory defect). Каждый отдельный модуль он делает правильно, но не видит как они взаимодействуют — auth-модуль "работает", но в связке с другими создаёт дыру (objective defect). Наконец, AI не знает специфики твоего деплоя и стека — пишет шаблонный код без учёта реальной архитектуры (knowledge defect).
Self-check работает потому что AI умеет критиковать лучше, чем создавать. Написать безопасный код с нуля — сложно: нужно держать в голове всё сразу. Найти проблему в готовом коде — проще: один фокус, конкретный объект. Self-check переключает модель из режима "генерирую" в режим "проверяю" — другая задача, другое качество внимания.
Production request меняет контекст поколения. LLM генерирует текст исходя из контекста промпта. "Напиши приложение" → модель активирует паттерны демо-кода и туториалов. "Напиши production-ready приложение" → модель активирует паттерны рабочего, задеплоенного кода с обработкой ошибок и проверками. Это не команда — это настройка контекста, из которого берутся паттерны.
Рычаги управления: - Замени "OWASP Top 10" на конкретный список — если знаешь свои риски (например, "проверь SQL-инъекции и открытые ключи"), AI проверит точнее - Добавь конкретные угрозы — "у меня финтех-приложение, особое внимание на авторизацию и логирование" — знание defect компенсируется явной постановкой - Попроси промежуточные self-check — для больших приложений проси проверку после каждого модуля, не только в конце (борьба с memory defect) - Укажи деплой-среду — Railway, Vercel, Supabase — AI учтёт специфику платформы
Шаблон промпта
Создай production-ready {описание приложения}.
Функционал:
- {функция 1}
- {функция 2}
- {функция 3}
Обязательные требования к безопасности:
- Все данные от пользователей — валидировать и очищать перед использованием
- Авторизация — настоящая реализация, без заглушек и пропуска всех запросов
- Секреты и API-ключи — только через переменные окружения (.env), не хардкодить
- Входящие запросы к базе данных — защищены от инъекций
После написания кода — выполни самопроверку:
Пройдись по этому списку и проверь своё решение:
1. Сломанная авторизация — есть ли незащищённые маршруты?
2. Инъекции — все ли запросы к БД через параметры, не конкатенацию?
3. Открытые секреты — нет ли API-ключей в коде или фронтенде?
4. Незафильтрованный ввод — все ли данные от пользователей проверяются?
5. Заглушечная логика — нет ли мест где auth "всегда пропускает"?
Для каждого пункта: статус (ОК / нашёл проблему) и что сделал.
Что подставлять:
- {описание приложения} — "форма записи + админка", "лендинг с CRM", "API для мобильного приложения"
- {функция N} — конкретные фичи, которые нужны
- Список проверок можно сократить до самых важных для вашего типа приложения
🚀 Быстрый старт — вставь в чат:
Вот шаблон для безопасного вайб-кодинга. Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит какой функционал нужен и какой стек/платформа — потому что от этого зависит что именно проверять в self-check. Она возьмёт структуру шаблона и заполнит под твой контекст.
Ограничения
⚠️ Не устраняет всё: Self-check снижает количество уязвимостей, но не до нуля. Knowledge defect — нехватка знаний о специфике вашего деплоя — промптом компенсируется частично. Критические системы всё равно нужен человек с security-экспертизой.
⚠️ Memory defect в длинных сессиях: Чем длиннее диалог с AI-агентом, тем больше он "забывает" про требования безопасности из начала. Self-check в конце помогает, но в многочасовых сессиях лучше делать промежуточные проверки.
⚠️ Уязвимости архитектурного уровня: Часть дыр возникает не в коде, а в решениях о структуре приложения — как компоненты взаимодействуют друг с другом. Промпт-инструкции не всегда достигают этого уровня. Это самая сложно устранимая категория.
⚠️ Отсутствие гарантий деплоя: Исследование показало — даже приложения с "улучшенными промптами" деплоятся без полноценного аудита. Self-check это шаг вперёд, не финальная проверка.
Как исследовали
Исследователи собрали 10 517 реальных открытых вайб-кодинг-приложений с GitHub — находили их по "отпечаткам" агентов (Claude Code оставляет папку .claude/, Lovable — метатег в HTML). Из них 1 170 были реально задеплоены и доступны из интернета. Выборку 200 приложений прогнали через четыре независимых AI-аудитора (Claude + GPT в двух разных конфигурациях), потом два эксперта вручную верифицировали каждую находку — проверяли, можно ли уязвимость реально эксплуатировать. Итог: 1 471 подтверждённая уязвимость в 200 приложениях.
Самое интересное — как тестировали митигации. Исследователи взяли одни и те же приложения и пересоздавали их с разными условиями: более мощная модель, более умный агентный фреймворк, специальные промпты. Оказалось, что простые промпт-техники победили дорогие инфраструктурные решения — что противоречило интуиции. Более сложные агентные системы давали меньший прирост безопасности, чем правильно сформулированный запрос. Для исследователей это был сюрприз: они ожидали обратное.
Интересная деталь: 94% всех вайб-кодинг приложений — это веб-приложения. Игры — второе место с долей 1.2%. Типичное вайб-кодинг приложение: 8 351 строка кода, 101 файл, разработка за 9.8 дней. "Ворваться и выдать" — стиль разработки, при котором security review не предусмотрен по природе процесса.
Оригинал из исследования (опционально)
Авторы не публикуют точный текст "production + self-check" промпта в статье — они описывают условие эксперимента. Из описания следует что тестировались запросы двух типов:
[Production request condition]
Generate a production-ready application that follows security best practices,
including proper authentication, input validation, and secure handling of
credentials.
[Self-check request condition]
After generating the application, review your implementation against the
OWASP Top 10 security risks and fix any identified vulnerabilities.
Контекст: Исследователи тестировали эти условия как отдельные и в комбинации — комбинация дала максимальный эффект.
Адаптации и экстраполяции
1. Адаптация контекста — те же принципы для любого сложного AI-задания (не только код)
Три системных сбоя (память, локальная оптимизация, нехватка знаний) работают не только в вайб-кодинге. Они воспроизводятся в любой длинной сессии с AI — написание большого документа, разработка стратегии, создание системы промптов.
💡 Адаптация для бизнес-документов:
Напиши [документ] в том виде, в котором его можно сразу отдать [аудитории]. После написания — проверь себя: 1. Нет ли утверждений без обоснования? 2. Нет ли противоречий между разными частями? 3. Закрыты ли очевидные возражения аудитории? 4. Нет ли мест где логика "висит в воздухе"? Для каждого пункта: статус и что исправил.
2. Адаптация техники: промежуточные self-check против memory defect
🔧 Техника: self-check после каждого модуля → борьба с забыванием
Memory defect — AI забывает требования по мере роста диалога. Решение: не ждать финального self-check, просить его после каждого крупного блока.
[После написания auth-модуля] Стоп. Перед тем как двигаться дальше — проверь этот модуль: авторизация настоящая или заглушка? Есть ли незащищённые маршруты? Исправь, подтверди — продолжим.Это разбивает длинную сессию на проверяемые отрезки. Каждый модуль — своя точка контроля.
3. Экстраполяция: компенсация трёх дефектов через структуру промпта
Понимание трёх root causes даёт систему для любой задачи:
[Против memory defect] В конце каждого раздела — сводка принятых решений и почему. [Против objective defect] После завершения — проверь: нет ли конфликтов между частями? [Против knowledge defect] Контекст задачи: {специфика вашей ситуации, которую AI не знает по умолчанию}
Три строки, которые компенсируют системные ограничения AI в любом сложном задании.
Ресурсы
Understanding the (In)Security of Vibe-Coded Applications
Junquan Deng (Independent Researcher) · Zhiyu Fan (Microsoft, UK) · Ruijie Meng (CISPA Helmholtz Center for Information Security, Germany)
Датасеты упомянутые в работе: VIBEAPPS (10 517 приложений), VIBEVULNS (1 471 уязвимость)
Инструменты вайб-кодинга из исследования: Claude Code (Anthropic), Lovable
OWASP Top 10 — стандарт классификации веб-уязвимостей: owasp.org/www-project-top-ten