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

Дополнительные инструкции по работе с Ailoot доступны в документации.

Почему приложения, созданные с помощью ИИ, часто оказываются уязвимыми?#

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

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

Есть и настройки самой платформы. Некоторые сервисы по умолчанию позволяют обращаться к новому проекту извне. Если создатель не знает, что доступ нужно ограничить, проект может остаться публичным.

ИИ-агент также может случайно опубликовать секреты. Например, команда git add . добавит все подходящие файлы, а последующий git push отправит их в удалённый репозиторий. Если .env не исключён настройками Git, вместе с кодом могут раскрыться ключи и пароли.

Какие ошибки уже приводили к утечкам в приложениях, созданных с помощью ИИ?#

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

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

Tea и чувствительная информация. В июле 2025 года из приложения Tea, предназначенного для анонимных отзывов о людях, утекли около 72 000 изображений, в том числе 13 000 селфи и фотографий документов, а позднее — более миллиона личных сообщений. В опубликованном описании инцидента среди технических причин указаны открытое хранилище и недостаточная проверка доступа. Этот случай напоминает, что особенно важно ограничивать доступ к чувствительным данным.

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

Какие два направления безопасности нужно учитывать?#

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

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

Второе направление — опубликованное приложение. Это сайт или сервис, доступный пользователям через интернет. Злоумышленники могут искать открытую базу, отправлять поддельные запросы или пытаться получить доступ к чужим аккаунтам. В таких ситуациях уязвимости обычно заложены в настройках и коде приложения.

Anthropic, разработчик Claude, описывает общий принцип защиты так: сначала нужно ограничить среду, в которой работает модель, а затем задавать правила её поведения.

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

Правила безопасности можно закрепить в CLAUDE.md, чтобы агент учитывал их при работе над проектом. Важно формулировать их ясно и поддерживать в актуальном состоянии.

Что может сделать ИИ-агент с доступом к компьютеру?#

Один из недооценённых рисков — агенту выдали слишком широкие полномочия. Для этого не нужен внешний злоумышленник: агент может использовать возможности, доступные учётной записи, хотя пользователь не ожидал такого результата. Например, членство в группе docker может предоставить привилегии, сопоставимые с правами администратора. Поэтому ограничение полномочий важно даже при обычной разработке.

Здесь не обязательно предполагать злой умысел. Агент, которому поручили решить задачу, может обнаружить технический обходной путь. Если этот путь даёт доступ к ключам или рабочей системе, последствия могут быть серьёзными. Основное правило — минимальные права: предоставляйте агенту только тот доступ, который требуется для конкретной задачи.

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

1. Не запускайте агента с неограниченными правами на рабочей машине

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

2. Ограничьте чтение секретов

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

3. Храните производственные ключи отдельно

   Не размещайте ключи от рабочей базы и платёжного сервиса в папке, где агент меняет код. Для экспериментов используйте отдельную среду и тестовые ключи.

4. Используйте изоляцию инструментов

   Некоторые ИИ-инструменты выполняют команды в песочнице, ограничивающей доступ к остальной системе. Anthropic сообщает, что песочница Claude Code сокращает число запросов на разрешение примерно на 84 процента; такой режим может одновременно повысить изоляцию и упростить работу.

Пример запрещающих правил для Claude Code — настройки доступа в формате JSON:

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

Где хранить API-ключи и пароли?#

Одна из самых частых и легко предотвратимых ошибок — хранение ключей прямо в коде. API-ключ платёжного сервиса, пароль базы данных и токен бота относятся к секретам. Поместите их в отдельный файл .env и внесите .env в .gitignore, чтобы Git не добавлял его к коммитам.

Вот что стоит проверить:

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

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

2. Проверьте удалённый репозиторий

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

3. Если ключ уже опубликован, отзовите его и создайте новый

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

4. Ограничьте полномочия ключей

   Если ключу нужен только доступ для чтения, не выдавайте ему права на изменение. Так возможные последствия утечки будут меньше.

Почему без RLS данные базы могут быть доступны посторонним?#

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

Документация Supabase указывает, что таблицы без RLS доступны через API публично.

Главная ловушка для вайб-кодинга связана с тем, как создаются таблицы. При создании через интерфейс панели Supabase защита может включаться автоматически, а при выполнении SQL-команды, сгенерированной ИИ, её настройки нужно проверять отдельно. Не предполагайте, что RLS включён: убедитесь в этом для каждой таблицы.

Что сделать:

1. Попросите агента проверить таблицы

   Напишите: «покажи мне все таблицы, у которых выключен RLS». Полученный перечень используйте как список для проверки.

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

   Добавьте правила доступа, например разрешите каждому пользователю видеть только собственные строки.

3. Проверьте настройки в панели Supabase

   Убедитесь, что для каждой нужной таблицы показан статус «RLS enabled». Если защита отключена, настройте её.

4. Проверьте доступ от имени обычного пользователя

   Войдите под обычной учётной записью и попробуйте запросить данные другого пользователя. Если запрос заблокирован, правило доступа действует как задумано.

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

Можно подумать, что администраторская функция защищена, потому что обычный пользователь не видит соответствующую кнопку. Но кнопка — лишь часть интерфейса браузера. Запрос можно отправить напрямую. Если сервер повторно не проверит права, он может выполнить действие для неподходящего пользователя.

Один из распространённых типов ошибок называется IDOR. Например, пользователь открывает свой заказ по адресу с id=123, меняет номер на id=124 и получает доступ к чужому заказу, если сервер не проверяет владельца записи. Поэтому важно проверять доступ не только в интерфейсе, но и при обработке каждого запроса.

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

Как проверить код на уязвимости без навыков программирования?#

Первичную проверку можно поручить ИИ-инструментам, которые анализируют код на распространённые уязвимости. Среди доступных решений — два инструмента Anthropic для Claude Code.

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 рекомендует рассматривать его как один слой защиты, а не полноценную замену процессу безопасности.

В рамках Project Glasswing Anthropic вместе с организациями-партнёрами использовала модели для выявления критических уязвимостей. Компания оценивала, что масштабная атака могла бы затронуть более 100 миллионов человек. Этот пример показывает, насколько важны систематическая проверка и ограничение последствий возможных атак.

Можно ли доверять навыкам и расширениям из интернета?#

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

Проверьте автора, описание и источник распространения. Не устанавливайте инструмент лишь по краткой рекомендации; незнакомые решения сначала испытайте в отдельной среде, не имеющей доступа к рабочим ключам.

Что поможет восстановиться после сбоя: резервные копии и откат#

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

Следуйте двум правилам.

Создавайте резервные копии достаточно часто. Если в приложении есть ценные данные, интервал копирования должен соответствовать допустимым потерям. Например, можно настроить автоматические копии каждые 30 минут. Проверьте, какие возможности резервного копирования предоставляет ваша база данных.

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

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

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

1. Секреты находятся в .env, а файл внесён в .gitignore. В коде и публичном репозитории ключей быть не должно.
2. Ключи имеют минимально необходимые права. Производственные ключи отделены от среды, в которой работает агент.
3. RLS включён для всех таблиц с пользовательскими данными и дополнен подходящими правилами доступа.
4. Сервер проверяет права при каждой операции с данными. Скрытой кнопки недостаточно; проверьте, можно ли получить чужие данные, изменив id в адресе.
5. Webhook проверяет подпись. Обработчики внешних уведомлений, например от платёжной системы или формы, должны проверять подлинность запроса. Для такого обработчика нужна проверка подписи.
6. Ограничена частота запросов (rate limiting), особенно для входа в аккаунт и ресурсоёмких операций. Это мешает перебирать пароли и создавать чрезмерную нагрузку или расходы.
7. Агент не работает с неограниченным доступом на машине с производственными ключами. Для .env настроен запрет чтения.
8. Резервные копии создаются регулярно и проверены. Убедитесь, что можете восстановить данные, а не только полагайтесь на наличие копий.
9. Код проверен командой /security-review или плагином security-guidance. Обнаруженные проблемы устранены.
10. Сторонние навыки и расширения проверены до установки. Не устанавливайте незнакомые инструменты вслепую.

С чего начать сегодня?#

Не пытайтесь внедрить все рекомендации за один вечер. Начните с трёх основных действий:

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

Затем проходите оставшиеся пункты чек-листа по мере роста проекта и появления в нём денежных операций или пользовательских данных.

Безопасность приложения — ответственность его владельца. Не обязательно становиться специалистом по защите систем, но важно самому проверить основные настройки и последствия, прежде чем открыть сервис пользователям.

Для дальнейшей работы с моделями перейдите в Ailoot.