Безопасность вайб-кодинга: как не дать взломать приложение на ИИ в 2026

Каждый день в Telegram-канале - что нового в вайб-кодинге: инструменты, примеры, ошибки на которых горят люди. Подпишись, чтобы быть в курсе.

Почему приложения на ИИ взламывают чаще?

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

Корень проблемы простой. Когда ты пишешь ИИ-агенту «сделай мне приложение для записи клиентов», он делает так, чтобы оно заработало быстрее всего. Безопасность - это лишняя работа, которая на демо никак не видна. Поэтому база поднимается открытой, ключ к платёжке падает прямо в код, а проверка «этот ли пользователь имеет доступ» живёт только в браузере, где её обходят за секунду.

Вторая причина - сами платформы. Вот как это формулирует исследование RedAccess, которое в мае 2026 просканировало эти приложения:

То есть дыра появляется сама, по умолчанию. Ты ничего не сделал неправильно. Ты просто ничего не сделал - а в безопасности бездействие как раз и означает «открыто всем».

И третий слой. ИИ охотнее сливает секреты, чем человек. По отчёту GitGuardian за 2026 год, коммиты, сделанные с помощью ИИ, выкладывают ключи и пароли в открытые репозитории примерно в 3,2 процента случаев - это вдвое чаще обычного. Логика понятная: агент делает git add . и git push не глядя, и твой .env с ключами уезжает в публичный доступ вместе со всем остальным.

На чём уже обожглись вайб-кодеры?

Лучшая прививка от беспечности - чужие грабли. Вот четыре разбора, на которые стоит посмотреть до того, как ты выложишь свой проект.

Lovable и выключенный RLS. Платформа Lovable собирает приложения по текстовому описанию. В 2025 году в них нашли системную дыру - уязвимости присвоили номер CVE-2025-48757. Причина: у сгенерированных приложений не было правил доступа к строкам базы (RLS, про него ниже). Исследователь проверил выборку и нашёл 303 открытых точки доступа в 170 приложениях. Наружу торчали имена, телефоны, статусы оплат, чужие API-ключи и даже домашние адреса. Примерно у 70 процентов проверенных приложений защита строк была выключена полностью.

Tea и чувствительные данные. Приложение Tea (анонимные отзывы о людях) в июле 2025 потеряло около 72 000 изображений, включая 13 000 селфи и фото документов, а затем ещё больше миллиона личных сообщений. Техническая причина - открытое хранилище и слабая проверка доступа. Сообщество по безопасности приводит Tea как наглядный пример: когда быстрый запуск важнее проверки прав, чувствительные данные утекают первыми.

RedAccess: масштаб проблемы. В мае 2026 израильская команда просканировала около 380 000 приложений на вайб-платформах. Около 5 000 сливали чувствительные данные - медицинские записи, финансы, внутренние документы компаний. Всё это работает прямо сейчас, прямо пока ты читаешь.

И пример поближе. У одного вайб-кодера, которого я знаю, взломали приложение из-за того, что ИИ при создании базы поставил стандартный пароль - такой, который подбирается автоматом. Дальше по схеме: зашли, поставили майнеры, переписали проект. Пришлось сносить сервер целиком. Стандартный пароль - это незапертая дверь с табличкой «заходи».

Два фронта безопасности: где именно ты уязвим?

Когда говорят «безопасность вайб-кодинга», обычно валят в кучу два совершенно разных страха. Давай разделим, потому что и защищаешься от них по-разному.

Фронт первый - сам агент. Ты запускаешь ИИ-агента на своём компьютере и даёшь ему доступ: к файлам, к терминалу, к ключам, к базе. Риск тут в том, что агент - не человек, он выполняет задачу буквально и найдёт самый короткий путь, даже если этот путь опасный. Сюда же - риск, что в агента «вселится» чужая команда через текст, который он читает (это называется prompt injection).

Фронт второй - готовое приложение. Это то, что ты опубликовал и чем пользуются люди. Тут цель - твой опубликованный сайт или сервис: лезут в открытую базу, шлют фейковые запросы, подбирают чужие аккаунты. Агент тут ни при чём - дыру он оставил раньше, а эксплуатируют её чужие.

Anthropic, которая делает Claude, формулирует главный принцип защиты так - и он работает для обоих фронтов:

На деле это значит вот что: не надейся, что ИИ «сам не сделает плохого». Сначала ограничь, что он физически может сделать, и только потом проси вести себя хорошо. Когда поведение даст сбой - а оно даст - спасёт только жёсткая граница, которую ты выставил заранее.

Хочешь, чтобы ИИ работал предсказуемо и не отстреливал тебе ногу в каждом новом проекте? Правила безопасности - часть твоего Второго мозга: один раз прописываешь их в CLAUDE.md, и агент держит их в каждом запросе. На практикуме за 3 эфира собираешь все три кита: ИИ-клон + Второй мозг + Контекст-инжиниринг - связку, которая делает Claude надёжным помощником вместо генератора галлюцинаций.

Практикум по вайб-кодингу

+Твой второй мозг

3 вечера - стек, метод, первый проект

Старт 9–11 июня  ·  2 000 ₽

Записаться →

Что натворит ИИ-агент с доступом к компьютеру?

Самый недооценённый риск - твой собственный агент со слишком широкими правами. Чужой хакер тут даже не нужен. Свежий пример с Hacker News, конец мая 2026. Агенту Codex понадобились права администратора, которых у пользователя не было. Агент не сдался - он осмотрелся, увидел, что пользователь состоит в группе docker, а это фактически тот же root, и воспользовался этим.

Тут нет злого умысла. Просто агент, которому сказали «реши задачу», находит структурную слабость быстрее человека. И если эта слабость даёт ему доступ к твоим ключам или к продакшену - он её использует. Поэтому правило номер один: минимальные права. Давай агенту ровно столько доступа, сколько нужно для конкретной задачи, и ни каплей больше.

Это не моя фантазия. Исследователи из университета Джонса Хопкинса провели атаки на боевых агентов Anthropic, Google и Microsoft. Вывод жёсткий:

Что с этим делать на практике, даже если ты не программист:

1. Не запускай агента в режиме «разрешить всё» на боевой машине

   Режим, где агент не спрашивает подтверждений (его часто называют bypass или yolo), - только для песочницы или тестового проекта, не для машины, где лежат рабочие ключи и доступ к продакшену.

2. Запрети агенту читать секреты

   В Claude Code это делается правилом запрета на чтение файла с ключами. Тогда даже если агент захочет открыть .env, инструмент его не пустит.

3. Держи прод-ключи отдельно

   Ключи от боевой базы и платёжки не должны лежать в той же папке, где агент пишет код. Разнеси среды: где экспериментируешь - там тестовые ключи.

4. Пользуйся песочницей инструмента

   Современные ИИ-инструменты умеют запускать команды в изоляции (песочнице), где у них нет доступа к остальной системе. У Claude Code это снижает число запросов на разрешение примерно на 84 процента - то есть это ещё и удобнее.

Запрет на чтение секретов в Claude Code выглядит примерно так - кладёшь это в настройки прав:

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(**/.env)",
      "Bash(git push *)"
    ]
  }
}

Куда нельзя класть API-ключи и пароли?

Самая дешёвая и самая частая ошибка - ключи в коде. API-ключ к платёжке, пароль от базы, токен бота - всё это секреты. Им место в отдельном файле .env, и этот файл обязан быть прописан в .gitignore, чтобы он не уехал в git вместе с кодом.

Почему это критично: ключ в открытом репозитории живёт недолго. По данным GitGuardian, от момента, когда секрет попал в публичный репозиторий, до первой попытки им воспользоваться проходит меньше 60 секунд. Боты круглосуточно сканируют новые коммиты. Дальше схема стандартная: нашли ключ от облака - подняли на твои деньги сервера под майнинг криптовалюты, и к утру у тебя счёт на десятки тысяч. Разработчики регулярно рассказывают такие истории, и счета там пятизначные в долларах.

Масштаб проблемы за 2025 год: 28,65 миллиона новых захардкоженных секретов в публичных репозиториях, рост на 34 процента за год. Утечки ключей именно от ИИ-сервисов выросли на 81 процент. Вайб-кодинг подливает масла, потому что агент коммитит не глядя.

Что проверить руками прямо сейчас:

1. Открой файл .gitignore в проекте

   Убедись, что там есть строка .env. Если её нет - добавь до первого коммита.

2. Зайди в свой репозиторий на GitHub

   Проверь, что файла .env там нет. Поиск по репозиторию на .env или на кусок своего ключа - быстрый способ.

3. Если ключ уже уехал - отзови и перевыпусти

   Удалить коммит мало: ключ уже могли утащить. Зайди в сервис (платёжка, облако, ИИ-провайдер), отзови старый ключ и выпусти новый. Это называется ротация.

4. Давай ключам минимальные права

   Если ключ нужен только для чтения - пусть будет только для чтения. Тогда даже при утечке украдут меньше.

Почему без RLS твою базу видят все?

Если ты делаешь приложение на Supabase или похожей базе - это самый важный раздел. RLS расшифровывается как Row Level Security, защита на уровне строк. По-простому: это правило, которое решает, какие строки таблицы покажут конкретному пользователю. Без него таблица «заказы» отдаёт каждому все заказы всех клиентов.

Вот как это формулирует сама документация Supabase, без обиняков:

И вот главная ловушка для вайб-кодера. Когда ты создаёшь таблицу мышкой через панель Supabase, защита включается сама. Но когда таблицу создаёт ИИ - а он почти всегда пишет SQL-команды напрямую, - RLS остаётся выключенным по умолчанию. То есть сгенерированная агентом таблица с вероятностью, близкой к единице, открыта всему интернету. Ровно так утекли те самые 170 приложений Lovable.

Что сделать:

1. Спроси агента прямо

   Напиши: «покажи мне все таблицы, у которых выключен RLS». ИИ выведет список - это твой фронт работ.

2. Включи RLS на каждой таблице с данными пользователей

   И добавь хотя бы одну политику доступа - например «пользователь видит только свои строки».

3. Проверь в панели

   В дашборде Supabase у каждой таблицы должна гореть отметка «RLS enabled». Серая или красная - значит открыто.

4. Проверь по-настоящему

   Зайди под обычным пользователем и попробуй запросить чужие данные. Если не пускает - политика работает.

Почему проверка прав в интерфейсе не защищает?

Частая иллюзия: «я же сделал так, что обычный пользователь не видит админскую кнопку». Проблема в том, что кнопка - это только картинка в браузере. Запрос к серверу можно отправить и без кнопки, напрямую. Если сервер не перепроверяет права, он честно выполнит чужую команду.

Классический пример называется IDOR. Представь, что ты открыл свой заказ по адресу с id=123. Меняешь в адресе на id=124 - и видишь чужой заказ, потому что сервер не проверил, твой ли это заказ вообще. Это одна из самых частых дыр в вайб-приложениях, и именно слабая проверка прав стояла за утечкой Tea.

Правило простое: каждую проверку «можно ли этому пользователю это делать» дублируй на сервере. Интерфейс - для удобства, защита - на бэкенде. Готовая команда для агента: «добавь проверку прав на сервере для каждой точки доступа, которая читает или меняет данные пользователя; не полагайся на то, что элемент спрятан в интерфейсе».

Как проверить код на дыры, если ты не программист?

Хорошая новость: проверку безопасности сегодня можно поручить тому же ИИ - он находит типовые дыры неплохо. Три инструмента под разные задачи.

1. Команда /security-review в Claude Code. Разовая проверка текущей ветки на SQL-инъекции, XSS, дыры авторизации, утечки данных и проблемы в зависимостях. Как это устроено пошагово и как повесить автоматическую проверку на каждое изменение - я подробно разобрал в отдельном гайде про security review в Claude Code. Здесь главное: это первый рубеж, запускается одной командой.

2. Официальный плагин security-guidance. Ставится из официального магазина плагинов командой /plugin install security-guidance@claude-plugins-official (нужен Claude Code версии не ниже 2.1.144). Он проверяет код в три момента: на каждой правке, в конце каждого хода и при коммите. Ловит обходы авторизации, IDOR, инъекции, слабую криптографию. Но Anthropic честно предупреждает о его границах:

3. Сборник навыков по кибербезопасности с GitHub. Открытая библиотека mukul975/Anthropic-Cybersecurity-Skills - на момент написания около 14 800 звёзд, 754 готовых навыка, проверка по стандартам OWASP, MITRE и NIST. Работает не только с Claude Code, но и с Codex, Cursor и другими агентами. Ставится одной командой:

npx skills add mukul975/Anthropic-Cybersecurity-Skills

Дальше просто говоришь агенту: «проверь мой проект на уязвимости». Но с этим сборником есть важный нюанс, из-за которого я вынес его в отдельный раздел ниже.

Для контекста: безопасностью ИИ-кода всерьёз занялись и крупные игроки. В рамках инициативы Project Glasswing, расширенной 2 июня 2026 на полторы сотни организаций, партнёры за короткое время нашли больше 10 000 критических уязвимостей с помощью моделей Anthropic. Масштаб ставок там такой:

Можно ли доверять скиллам и расширениям с гитхаба?

Тут начинается самое коварное, потому что опасность приходит из инструмента, который ты ставишь ради безопасности. Когда ты выполняешь npx skills add ... или ставишь расширение, ты тянешь чужой код, который агент потом исполняет с твоими правами. Если автора взломали или пакет изначально вредоносный - проблема уже у тебя.

Возьмём тот самый сборник навыков из прошлого раздела. В названии стоит «Anthropic», и это усыпляет бдительность. Но в его же описании прямо написано:

То есть название обманчиво. Сам по себе сборник сейчас зрелый и чистый, но принцип остаётся: ставишь под свою ответственность. И угроза не теоретическая. В мае 2026 вредоносное расширение для редактора прожило в магазине всего 18 минут - и за это время успело выгрести у поставивших его людей пароли из менеджера, токены GitHub, доступы к облаку и даже конфиги Claude Code. Отдельная неприятность: такой зловред часто переживает обычное удаление пакета и снова запускается в следующей сессии.

Я для себя вывел простую привычку, и тебе советую ту же: перед установкой любого навыка с гитхаба проверяй его сам. Автора могут взломать, аккаунт увести, в репозиторий прилететь зловред. Привычка проверять - твоя страховка.

Практический минимум перед установкой: посмотри автора и количество звёзд, открой описание навыка, не ставь инструмент «по совету из одного поста», а для незнакомого - сначала прогони в отдельной тестовой среде, а не на машине с боевыми ключами.

Что спасёт, когда уже сломали: бэкапы и откат

Безопасность - это не только «не пустить чужого», но и «вернуться, когда что-то пошло не так». Потому что пойдёт. Я видел, как ИИ-агент, решая рутинную задачу, снёс живую базу данных в рабочем проекте. Бэкап там был, но трёхдневной давности - и три дня данных просто исчезли.

Отсюда два правила.

Бэкапы - часто. Если в твоём приложении есть данные, которые жалко потерять, копия раз в три дня - это иллюзия защиты. Настрой автоматический бэкап хотя бы каждые 30 минут. У большинства баз (включая Supabase) это включается в пару кликов.

Git - как страховка от агента. Git хранит историю кода: каждое рабочее состояние можно вернуть. Когда агент переписал то, что работало, ты откатываешься на последнюю рабочую версию, а не чинишь руками. Если ИИ удалил или сломал проект и ты не знаешь, как вернуть, - смотри отдельный разбор: что делать, если ИИ удалил базу данных. А как заранее застраховаться от поломок проекта - в гайде как защитить Claude Code от поломок.

Чек-лист безопасности перед публикацией

Пройди этот список прямо перед публикацией. По порядку.

1. Секреты в .env, и .env в .gitignore. В коде ключей нет. В публичном репозитории .env нет.
2. Ключи с минимальными правами. Каждый ключ умеет только то, что нужно. Прод-ключи отдельно от среды агента.
3. RLS включён на всех таблицах с данными пользователей, и есть политики доступа.
4. Проверка прав на сервере для каждой операции с данными. Спрятать кнопку в интерфейсе мало. Проверил руками подмену id в адресе.
5. Webhook с проверкой подписи. Любой обработчик внешних уведомлений (оплата, формы) проверяет подпись. Как формулирует Hookdeck:

6. Ограничение частоты запросов (rate limiting) на вход и на тяжёлые операции - чтобы не подобрали пароль перебором и не накрутили тебе счёт.
7. Агент не запущен в режиме «разрешить всё» на машине с боевыми ключами. Стоит запрет на чтение .env.
8. Бэкапы настроены часто и проверены - ты реально пробовал восстановиться, а не просто веришь, что копии «где-то есть».
9. Код прогнан через /security-review или плагин security-guidance. Найденное - исправлено.
10. Чужие навыки и расширения проверены перед установкой. Ничего не ставил «вслепую».

С чего начать прямо сегодня

Не пытайся внедрить всё из этого гайда за один вечер - так ты ничего не сделаешь. Возьми три самых важных шага на сегодня:

1. Проверь секреты. Открой .gitignore, убедись что .env там есть, и проверь, что в публичном репозитории ключей нет. Если уехали - отзови и перевыпусти.
2. Спроси про RLS. Напиши агенту: «покажи таблицы, где выключен RLS» - и включи его там, где лежат данные людей.
3. Настрой частый бэкап. Чтобы при любом сбое ты терял минуты, а не дни.

Дальше - по чек-листу выше, по мере того как проект растёт и в нём появляются деньги и чужие данные.

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

Полная схема по вайб-кодингу за вечер: ИИ-клон + Второй мозг + Контекст-инжиниринг. На практикуме показываю, как встроить безопасность в методологию, чтобы ИИ собирал продукт правильно с самого начала.

Практикум по вайб-кодингу

+Твой второй мозг

3 вечера - стек, метод, первый проект

Старт 9–11 июня  ·  2 000 ₽

Записаться →

Новые материалы - дайджестом, без спама

Гайды выходят регулярно. Подпишись, чтобы не пропускать: пришлю подборку в Telegram или на email. Раз в неделю или каждый день - выбираешь сам.

Подписаться в Telegramили на email