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

Почему приложениям, написанным с ИИ, нужен свой чек-лист

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

Чек-лист состоит из двух частей. Шаги 1-3 и 6-7 защищают приложение и нужны везде, где оно работает. Шаги 4 и 5 защищают сервер и нужны, если вы арендуете VPS. Если вы деплоите на управляемую платформу, большую часть шагов 4 и 5 берёт на себя провайдер, остальное остаётся на вас. Полный список для сервера: чек-лист безопасности VPS.

Шаг 1: уберите секреты из кода и из браузера

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

• Храните секреты в переменных окружения или в менеджере секретов, но не в исходниках, промптах и скриншотах. Ассистенты нередко вставляют ключ прямо в код, чтобы пример заработал.
• Добавьте .env в .gitignore до первого коммита. Проверьте, не попадал ли он в историю: git log --all --oneline -- .env. Любой вывод означает, что файл когда-то был закоммичен.
• Понимайте, какие ключи могут попадать в браузер. Всё, что отдаётся фронтенду, публично. Публикуемые (publishable) ключи рассчитаны на это, секретные нет: в документации Supabase сказано, что роль service role обходит row-level security, поэтому держите её только на сервере и не показывайте клиентам.
• Включите проверку секретов. Push protection на GitHub блокирует push, в котором есть жёстко прописанные учётные данные. По документации GitHub, для пользователей при push в публичные репозитории она включена по умолчанию, а защиту на уровне репозитория включает администратор.
• Меняйте ключ, а не просто удаляйте. Если ключ попал в репозиторий, чат или лог, удаление из файла его не вернёт. Отзовите ключ и выпустите новый. Порядок действий: открытые .env и .git.

Шаг 2: проверьте, кто что видит и меняет

Контроль доступа означает, что каждый запрос проверяется на сервере: для этого пользователя и для этой записи. Скрытая кнопка в интерфейсе контролем доступа не является, ведь запрос можно отправить и без кнопки. OWASP Top 10 относит нарушение контроля доступа к основным рискам веб-приложений, а код от ИИ может его пропустить без единой видимой ошибки.

• Проведите тест двух пользователей. Создайте два аккаунта, войдите вторым и запросите запись первого, подменив ID. Ожидаемый результат: отказ, а не данные.
• Включите row-level security на каждой доступной снаружи таблице, если используете Supabase или другой API-слой над Postgres. Документация Supabase предупреждает: таблица в открытой схеме без row-level security доступна на чтение и запись любой роли, у которой есть на неё права. Затем напишите политики и проверьте их как неавторизованный посетитель.
• Проверяйте админские маршруты на сервере. Странице администратора нужна серверная проверка роли в каждом вызове, а не только скрытая ссылка.
• Используйте проверенную систему входа вместо самодельной и включите двухфакторную аутентификацию (например, TOTP) для админов, а также для хостинга и Git, которые управляют приложением.
• Ограничьте частоту входа и сброса пароля, чтобы скрипт не перебирал тысячи паролей. Принцип описан в статьях ограничение частоты запросов и атака перебором.

Шаг 3: проверьте код и каждую зависимость

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

• Требуйте параметризованные запросы. Никогда не собирайте запрос к базе склейкой строк с пользовательским вводом.
• Проверяйте ввод и загрузки на сервере: размер, тип и место хранения файла.
• Убедитесь, что каждый пакет существует и это именно тот пакет. В исследовании Spracklen и соавторов, принятом на USENIX Security 2025, 16 моделей сгенерировали 576 000 образцов кода, и выдуманные имена пакетов нашлись минимум в 5,2% ответов коммерческих моделей и 21,7% ответов моделей с открытыми весами. Авторы предупреждают: злоумышленник может зарегистрировать такое имя и ждать. Перед установкой выполните npm view имя-пакета или откройте страницу в реестре и посмотрите возраст, авторов и репозиторий.
• Коммитьте lock-файл и ставьте зависимости из него на проде (для npm это npm ci), а после каждого изменения зависимостей запускайте npm audit или аналог для вашего языка.
• Отключите режим отладки на проде и удалите тестовые аккаунты, демо-маршруты и страницы ошибок, которые печатают трассировку.

Шаг 4: закройте сервер

Новый VPS сразу доступен из интернета, и автоматические попытки входа обычно находят его быстро. Эти пять настроек закрывают типичные двери. Делайте их по порядку и держите одну рабочую SSH-сессию открытой до последней проверки, потому что ошибка здесь может закрыть вам доступ (этот случай разобран в руководстве по восстановлению).

• Входите по SSH-ключам. Задайте PasswordAuthentication no и PermitRootLogin no в /etc/ssh/sshd_config, проверьте sudo sshd -t и перезагрузите службу. Подробнее: усиление SSH, вход по ключам и защита SSH от перебора.
• Запускайте приложение от обычного пользователя, не от root, и давайте ему только нужные права. См. sudo и минимальные привилегии.
• Файрвол с запретом по умолчанию. Сначала разрешите SSH, затем веб-трафик, затем включите:

  sudo ufw default deny incoming
  sudo ufw default allow outgoing
  sudo ufw allow OpenSSH
  sudo ufw allow 80/tcp
  sudo ufw allow 443/tcp
  sudo ufw enable

  Если вы меняли порт SSH, укажите свой. Подробнее: руководство по файрволу Linux и политика запрета по умолчанию.
• Ставьте обновления безопасности автоматически. На Debian и Ubuntu для этого есть unattended-upgrades. Общий порядок описан в руководстве по управлению патчами.
• Добавьте fail2ban, чтобы банить адреса, которые продолжают неудачно входить: руководство по настройке.

Шаг 5: закройте то, что не должно быть публичным

Проекты, написанные с ИИ, часто запускаются так же, как на ноутбуке разработчика: dev-сервер на порту 3000, база на порту по умолчанию, включённая панель отладки. Проверьте, что реально слушает сеть:

sudo ss -tlnp

Каждая строка, где локальный адрес 0.0.0.0 или [::], доступна снаружи, если её не блокирует файрвол.

• Держите базы данных и кэши закрытыми. PostgreSQL, MySQL, Redis и MongoDB должны слушать 127.0.0.1 или частную сеть, а не публичный адрес. См. открытые базы данных на VPS.
• Поставьте перед приложением обратный прокси, например nginx, и открывайте наружу только порты 80 и 443. Не выставляйте в интернет dev-сервер фреймворка. Меры защиты: безопасность nginx.
• Используйте HTTPS везде и добавьте базовые заголовки безопасности и HSTS. Сертификаты бесплатны и обновляются автоматически; см. продление Let's Encrypt и TLS/SSL.
• Помните про Docker. Порты контейнеров, опубликованные через -p, могут обходить правила ufw, поэтому привязывайте закрытые сервисы к localhost (127.0.0.1:5432:5432 в compose-файле) и никогда не монтируйте сокет Docker в контейнер приложения. Подробнее: безопасность Docker-хоста.
• Убедитесь, что .env и .git нельзя скачать с вашего домена. Откройте в браузере https://ваш-домен/.env: файл отдаваться не должен.

Шаг 6: ограничьте злоупотребления и неожиданные счета

Публичные точки входа, которые вызывают платный сервис (ИИ-модель, SMS, почтовый API), это приглашение: любой может скриптом слать запросы, а платите вы.

• Вызывайте платные API только с сервера, за авторизацией и с квотой на пользователя.
• Задайте жёсткие лимиты расходов и оповещения у каждого провайдера, включая облачный аккаунт.
• Ограничьте частоту запросов к дорогим маршрутам. В nginx объявите зону в блоке http и примените её к location:

  limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
  
  location /api/ {
      limit_req zone=api burst=20 nodelay;
  }

  См. limit_req.
• Поставьте перед сайтом CDN или прокси, чтобы гасить наплывы трафика. Варианты и фон: защита сайта малого бизнеса от DDoS и DDoS-атаки.

Шаг 7: держите ИИ-агентов на коротком поводке

Кодовые агенты умеют выполнять команды, менять файлы и работать с базами данных. В этом их смысл и их риск. В июле 2025 года heise сообщило, что ИИ-агент Replit удалил продуктивную базу данных во время заморозки кода, хотя пользователь говорил, что запретил ему что-либо менять. По тому же отчёту, агент затем заявил, что откат невозможен, хотя резервная копия существовала. История опирается в основном на скриншоты самого пользователя, а гендиректор Replit сообщил о внедрении автоматического разделения баз для разработки и продакшена. Вывод не зависит от деталей: указание в промпте не является границей прав.

• Разделите разработку и продакшен: разные базы и разные учётные данные. Агенту выдавайте только данные для разработки.
• Давайте агенту минимально достаточные права: пользователь базы только для чтения, где это возможно, без root и без общего sudo.
• Требуйте подтверждения для разрушительных действий: удалений, DROP, миграций, force push и всего, что касается продакшена.
• Работайте в отдельной ветке и читайте diff перед слиянием, чтобы каждое изменение можно было проверить и откатить.
• Исходите из того, что ошибка случится, и убедитесь, что шаг 8 её переживёт.

Шаг 8: делайте бэкапы данных и репетируйте восстановление

Git хранит код, но не данные ваших пользователей. Бэкап, который вы ни разу не восстанавливали, это надежда, а не бэкап.

• Следуйте правилу 3-2-1: три копии на двух типах носителей, одна вне площадки. Снимок у провайдера в том же аккаунте считается одной копией, а не тремя. Полное руководство: стратегия бэкапов VPS.
• Делайте дамп базы по расписанию (для PostgreSQL pg_dump) и копируйте его с сервера.
• Храните одну копию, которую нельзя изменить или удалить с сервера, например с помощью object lock. Это же защита от шифровальщиков.
• Раз в месяц восстанавливайте дамп во временную базу и записывайте, сколько это заняло и сколько данных потеряно. Эти два числа и есть ваши RPO и RTO.

Шаг 9: наблюдайте и знайте, что делать при сбое

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

• Добавьте проверку доступности, которая пишет вам на почту или в мессенджер, и оповещения о заполненном диске, нехватке памяти и повторяющихся неудачных входах.
• Храните логи, которые переживают перезагрузку, и раз в неделю просматривайте их через journalctl. Практическая настройка: мониторинг сервера и анализ логов. Полноценный SIEM вам, скорее всего, пока не нужен; см. Wazuh и journald.
• Сейчас же напишите план действий при инциденте из пяти строк: кто решает, как изолировать сервер, какие секреты менять первыми, где бэкапы и кому звонить. Полная процедура: как обнаружить взлом сервера и ответить на него; термины объяснены в статьях реагирование на инциденты и сдерживание.
• Знайте, когда передать задачу. Если в приложении лежат данные клиентов, а безопасностью в команде никто не занимается, сравните управляемую защиту и самостоятельную.

Весь чек-лист на одном экране

• Нет секретов в коде, промптах и браузере; утёкшие ключи заменены.
• Лимиты расходов и оповещения на каждом платном API.
• Тест двух пользователей пройден; row-level security включена; админские маршруты проверяются на сервере.
• Двухфакторная аутентификация на админке, хостинге и Git.
• Код про деньги, вход, файлы и базу прочитан; запросы параметризованы.
• Каждая зависимость проверена; lock-файл закоммичен; отладка выключена.
• SSH только по ключам, без входа root, файрвол с запретом по умолчанию, автообновления.
• Публично открыты только порты 22, 80 и 443; базы на localhost; HTTPS и заголовки включены.
• Ограничения частоты запросов и прокси перед приложением.
• ИИ-агенты работают в ветке, с данными для разработки, и спрашивают разрешения на разрушительные действия.
• Бэкапы 3-2-1, одна неизменяемая копия, восстановление проверено в этом месяце.
• Оповещения о доступности и логах работают; план инцидента написан.

Углубляйтесь: по руководству на каждый шаг

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

• Секреты: что делать, если утёк ключ API и поиск открытых файлов .env и .git.
• Контроль доступа: row-level security в Supabase и правила безопасности Firebase, а также термины row-level security и SQL-инъекция.
• Зависимости: термин слопсквоттинг объясняет риск пакетов из шага 3, а управление секретами и переменные окружения относятся к шагу 1.
• Сервер и деплой: безопасный деплой приложения на VPS и безопасность Docker Compose для небольших приложений.
• ИИ-инструменты: файл правил безопасности для копирования, безопасная работа с ИИ-агентами и термин промпт-инъекция.