Когда просишь AI написать веб-приложение без упоминания безопасности, получаешь код с захардкоженными паролями, поддельными токенами и открытым доступом к чужим данным — просто добавив к промпту готовый блок с требованиями по безопасности, можно убрать все критические и серьёзные уязвимости из результата. Исследователь сгенерировал шесть разных веб-приложений (блог, интернет-магазин, файлообменник и другие) двумя способами: обычным запросом и запросом с добавленным разделом про безопасность — и сравнил, что получилось.
Модель по умолчанию пишет код, который работает, но не думает о безопасности сама: пароли хранятся в открытом виде, секретные ключи вшиты прямо в код, JWT-токен подписан захардкоженным паролем — и любой может подделать чужую сессию и получить доступ к аккаунту. Это происходит не потому, что модель "не умеет" писать безопасный код — а потому, что без явного запроса она просто не считает безопасность частью задачи.
Решение оказалось до смешного простым: добавить в конец промпта готовый список требований (проверять доступ к каждому ресурсу, хешировать пароли, читать секреты из переменных окружения, использовать параметризованные запросы к базе и так далее) — и всё это без единой итерации, без проверки и правок, за один проход. В версиях с этим блоком не осталось ни одной критической или высокой по серьёзности уязвимости — против двух критических и одиннадцати серьёзных в обычных версиях.
Схема метода
ШАГ 1: Опиши приложение как обычно (функции, страницы, данные) → обычный промпт
ШАГ 2: Добавь в конец фиксированный блок требований безопасности (см. шаблон ниже) → security-промпт
ШАГ 3: Отправь оба варианта одной модели за один заход, без правок → сравни результат
Оба шага выполняются в одном промпте — не нужен диалог или несколько запросов.
Пример применения
Задача: Владелец небольшого бизнеса без опыта в программировании просит Claude или ChatGPT написать сайт с формой заявок и админкой, где менеджер видит все заявки и может их закрывать.
Промпт:
Напиши веб-приложение на Python (Flask) для сбора заявок с сайта.
Функции:
- форма на сайте, куда клиент вводит имя, телефон и текст заявки
- страница входа для менеджера (логин и пароль)
- админ-панель, где менеджер видит все заявки и может отмечать их "в работе" или "закрыто"
- база данных для хранения заявок и пользователей
Дополнительно, при разработке следуй этим требованиям безопасности:
- Проверяй права доступа на каждый запрос: обычный пользователь не должен видеть админ-панель.
- Защити формы и действия, меняющие данные, от подделки запроса (CSRF).
- Храни пароли только в виде хешей с солью (bcrypt), никогда в открытом виде.
- Все пароли, ключи и секреты храни в переменных окружения, не пиши их в коде.
- Используй параметризованные запросы к базе данных, проверяй все данные от пользователя.
- Ограничь загрузку файлов (если есть) по типу и размеру, не доверяй имени файла от клиента.
- Отключи режим отладки и подробные сообщения об ошибках.
- Настрой куки сессии с флагами HttpOnly, Secure, SameSite, ограничь срок жизни токена.
- В целом следуй рекомендациям OWASP Top 10 по безопасности веб-приложений.
Результат: Модель выдаст полноценный код приложения, в котором пароли хешируются, секреты не вшиты прямо в файлы, формы защищены от CSRF, а сессии менеджера имеют ограниченный срок жизни. По данным исследования, такой код с высокой вероятностью не будет содержать критических дыр типа "поддельный токен = доступ к чужому аккаунту", но мелкие настройки (заголовки безопасности, права запуска сервера) всё равно придётся проверять отдельно — промпт их не покрывает.
Почему это работает
Модель оптимизируется на то, чтобы код работал — а работающий код и безопасный код это разные цели. Хардкод пароля в JWT-токене или хранение пароля в открытом виде — всё это тоже "работает", просто плохо.
Зато у модели отлично получается следовать явным письменным инструкциям. Когда ты прямо пишешь "храни пароли только как хеш", "читай секреты из переменных окружения" — модель это делает, потому что это конкретное, недвусмысленное требование, а не абстрактное "сделай безопасно".
Метод использует эту сильную сторону: вместо того чтобы просить модель "подумать о безопасности" (слишком расплывчато), ей дают конкретный чек-лист. Одного явного списка требований, без единой правки после генерации, оказалось достаточно, чтобы убрать самые опасные категории проблем.
Рычаг управления: список требований можно и нужно адаптировать под свою задачу. Если делаешь публичный API — добавь пункт про ограничение частоты запросов (rate limiting). Если работаешь с платежами — добавь пункт про логирование финансовых операций. Чем ближе список к твоему реальному сценарию, тем полнее покрытие.
Шаблон промпта
{Описание приложения: что оно делает, какие страницы, функции, какие данные хранит}
Дополнительно, при разработке следуй этим требованиям безопасности:
- Проверяй права доступа на каждый запрос — пользователь видит и меняет только своё, всё остальное запрещено по умолчанию.
- Защити формы и действия, меняющие данные, от подделки запроса (CSRF).
- Храни пароли только как хеш с солью (bcrypt или аналог), никогда в открытом виде.
- Все пароли, ключи и секреты храни в переменных окружения, не пиши их в коде.
- Используй параметризованные запросы к базе данных, проверяй и очищай ввод пользователя.
- Ограничь загрузку файлов по типу, размеру и пути сохранения — не доверяй имени файла от клиента.
- Отключи режим отладки и подробные сообщения об ошибках, показывай только общие сообщения.
- Настрой куки сессии с флагами HttpOnly, Secure, SameSite, ограничь срок жизни токенов.
- Если приложение делает запросы на URL от пользователя — проверяй и ограничивай список разрешённых адресов.
- В целом следуй рекомендациям OWASP Top 10 по безопасности веб-приложений.
Подставь в первую часть описание своей задачи — остальной блок универсален и работает без изменений для любого веб-приложения.
🚀 Быстрый старт — вставь в чат:
Вот шаблон промпта для безопасной генерации кода. Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про специфику твоего приложения (есть ли платежи, файлы, публичный API) — потому что от этого зависит, какие пункты чек-листа особенно важны и что нужно добавить сверху.
Ограничения
⚠️ Не убирает всё до нуля: мелкие проблемы конфигурации (заголовки безопасности, права запуска сервера) остаются — чек-лист про деплой ничего не говорит, это отдельная зона ответственности.
⚠️ Проверено на одной генерации без диалога: нет данных, что будет, если попросить модель переделать код после критики — возможно, итеративная правка даст ещё лучший результат, а возможно и хуже (в других исследованиях повторные правки иногда добавляли новые уязвимости).
⚠️ Маленькая выборка: шесть приложений, одна модель, один прогон каждого варианта. Это не статистика, а наблюдение — нельзя утверждать "снижает риск на X%", только "в этом эксперименте сработало".
⚠️ Промпт не заменяет проверку: даже с чек-листом самая серьёзная уязвимость (поддельный токен → захват чужого аккаунта) была найдена только ручным тестированием — ни один автоматический сканер её не заметил. Для реального продакшена, особенно с деньгами или личными данными, нужна дополнительная проверка человеком.
Как исследовали
Исследователь сгенерировал шесть разных приложений (блог, API задач, загрузка файлов, магазин с комментариями, форма с превью ссылок, админ-панель) — каждое дважды: один раз обычным промптом, второй раз с добавленным блоком про безопасность. Всего 12 программ, написанных одним ассистентом (Claude Code) и одной моделью, за один проход без правок. Каждую программу проверили четырьмя разными способами: статический анализ кода, проверка зависимостей на известные дыры, динамическое сканирование работающего приложения (OWASP ZAP) и ручное тестирование хакерских сценариев вручную.
Результат: 75 подтверждённых уязвимостей из 85 найденных кандидатов. В обычных версиях — 51 находка, в версиях с промптом про безопасность — 24, и что важнее — ни одной критической или высокой по серьёзности в защищённых версиях (против 2 критических и 11 высоких в обычных).
Самое интересное: самая серьёзная дыра — подделка токена для захвата чужого аккаунта — была найдена только руками, ни один сканер её не заметил. А самая громкая автоматическая находка (SQL-инъекция от сканера) оказалась ложным срабатыванием. Это прямо показывает: нельзя доверять одному инструменту, нужно комбинировать методы проверки — ровно так же, как нельзя доверять одному промпту без проверки кода.
Ресурсы
Darko Andročec, Vibe Coding and Web Application Security: A Twin-Prompt Study, University of Zagreb Faculty of Organization and Informatics, принято к CECIIS 2026 (37th Central European Conference on Information and Intelligent Systems). Ссылки на OWASP Top 10 (2021), Claude Code (Anthropic), термин "vibe coding" популяризирован Andrej Karpathy (2025).