Почему ИИ-инструменты оставляют пробелы в безопасности

Почему AI-сгенерированный код отличается безопасностью

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

• Training data skews toward "make it work." Репозитории с открытым исходным кодом и учебные пособия доминируют в обучении LLM. Медианный репозиторий OSS был написан для решения проблемы, а не для того, чтобы служить образцом усиления безопасности. LLM изучает распространение кода в реальных условиях, а не распространение безопасного кода.
• Autocomplete is sticky. Когда вы вставляете фрагмент кода, использующий ключ service_role, он становится шаблоном для следующего файла. Автозаполнение Cursor предложит его в клиентском компоненте, которому оно никогда не принадлежало. Инструмент делает то, для чего он оптимизирован (скорость), но не знает границ безопасности.
• No long-term context or incident memory. Разработчик-человек, который сжег рабочую базу данных с отсутствующим предложением WHERE, переносит этот урок на долгие годы. У LLM нет эпизодической памяти. Каждый файл — это новое начало. Инструмент не изучает ваш последний обход RLS или анализ инцидентов вашей команды.
• Speed is the rewarded metric. Разработчики выбирают эти инструменты, потому что они быстро поставляются. Обратная связь по задержке немедленная и прямая. Обратная связь по безопасности отсутствует или задерживается — уязвимость обнаружена при сканировании FixVibe через три недели после поставки. LLM был оптимизирован для показателей вознаграждения людей в режиме реального времени.
• Implicit trust in platform defaults. Когда Cursor создает приложение Vercel, предполагается, что настройки по умолчанию Vercel усилены. Некоторые из них: auto-HTTPS, подписанные файлы cookie, защита от DDoS. Остальные нет: нет CSP по умолчанию, нет HSTS, разрешающий CORS. Сгенерированный код наследует предположения платформы, которые не всегда оправданы.

Пробел 1: Секреты в клиентских пакетах

Ключи сервисной роли API, токены OAuth и закрытые ключи попадают в пакеты JavaScript, отправляемые в браузер. FixVibe помечает их как выводы secrets.browser-storage и secrets.bundle-leak. Ключи можно обнаружить в исходных картах, минимизированном коде или открытом тексте JS.

Why it happens: Cursor вставка фрагмента Supabase, который инициализирует клиента с ролью службы, означает, что код теперь находится в режиме автозаполнения. Сгенерированный компонент React запрашивает «получить все элементы из базы данных», а Cursor предлагает импортировать сервис-клиент. Граница между серверным и клиентским кодом абстрактна для LLM.

Fix: Храните секреты в переменных среды, отмеченных NEXT_PUBLIC_, только для открытых ключей. Служебные ключи, частные ключи API и секреты подписи должны находиться в src/lib/secrets.ts с import 'server-only'. Используйте действия сервера или маршруты API для вызова конфиденциальных служб, а не клиентских компонентов.

Пробел 2: Отсутствует или неполный уровень безопасности на уровне строк

Таблицы Supabase создаются без включения RLS. Firebase Правила Firestore никогда не записываются или остаются в разрешительном тестовом режиме. Пользователи Anon могут читать и писать каждую строку. FixVibe помечает это как baas.supabase-rls и baas.firebase-rules.

Why it happens: RLS — это функция, специфичная для Postgres. LLM, обученные работе с Rails, Django, Laravel и Express, считают проверку аутентификации на уровне приложения нормой. Включение RLS на Supabase требует явных операторов ALTER TABLE и определений политики — шаблоны, менее распространенные в обучающих данных.

Fix: Для Supabase используйте RLS с ALTER TABLE public.table_name ENABLE ROW LEVEL SECURITY; ALTER TABLE public.table_name FORCE ROW LEVEL SECURITY; на каждой таблице. Разработайте политики, которые ограничивают строки аутентифицированным пользователем или организацией. Для Firebase никогда не оставляйте правила в качестве тестового режима по умолчанию; писать явные правила, применимые к аутентифицированному пользователю.

Пробел 3: путаница в границах аутентификации

Сессии проверяются на стороне клиента с помощью getSession() (который считывает непроверенный файл cookie). Магические ссылки не имеют срока действия. JWTs пропускает проверки aud и exp. Сброс пароля является обратимым. FixVibe помечает их как выводы active.auth-flow.

Why it happens: Supabase Auth, Clerk и подобные службы обрабатывают состояние сеанса, но их APIs имеют безопасные и небезопасные режимы. getSession() удобно, но не проверено. LLM видит удобство API чаще, чем безопасность в обучающих данных. Проверка токена на стороне сервера является абстрактной и требует явных заголовков HTTP или вызова промежуточного программного обеспечения.

Fix: Всегда используйте supabase.auth.getUser() на стороне сервера. Никогда не доверяйте getSession() на защищенных маршрутах. Подтверждайте JWTs в каждом запросе, проверяя exp, aud и подпись. Установите срок действия токена на 1 час для токенов доступа и используйте токены обновления для более длительных сеансов.

Пробел 4: Отсутствуют заголовки безопасности HTTP

Нет Content-Security-Policy, нет X-Frame-Options, нет Strict-Transport-Security, нет X-Content-Type-Options. FixVibe отмечает это как вывод headers.security-headers.

Why it happens: Заголовки безопасности зависят от платформы развертывания. Cursor генерирует код для Next.js; настройка CSP требует настройки next.config.js, промежуточного программного обеспечения или переопределения vercel.json. Их нет в каркасах проектов по умолчанию. Ментальная модель «заголовки предназначены для DevOps» все еще распространена.

Fix: Установите CSP в next.config.js или промежуточном программном обеспечении с поддержкой nonce: Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-...'; .... Добавьте HSTS: Strict-Transport-Security: max-age=31536000; includeSubDomains. Используйте заголовки vercel.json Vercel или промежуточное программное обеспечение для статических хостов.

Недостаток 5: неправильные настройки интеграции со сторонними организациями

Ключи Stripe, токены Sentry, ключи Anthropic API жестко запрограммированы или зафиксированы в репозиториях. Истоки аналитики слишком либеральны. Зависимости npm устарели. Сканирование FixVibe помечает их как находки в discovery.tech-fingerprint и наших средствах проверки секретов.

Why it happens: Интеграции вставлены из документации и туториалов. LLM копирует шаблон, включая все жестко запрограммированные значения. Дисциплина Env-var требует явной дисциплины в CI/CD, которую LLM не может обеспечить.

Fix: Используйте переменные среды для всех сторонних учетных данных. Храните секреты на своей платформе развертывания (Vercel, Netlify, Heroku или в хранилище). Проверяйте зависимости npm с помощью npm audit ежемесячно. Используйте Dependabot или Renovate для автоматических PR, когда доступны обновления безопасности.

Схема исправления

Закрытие этих пробелов не требует перестройки с нуля. Схема соответствует:

1. Audit: Запустите FixVibe в своем действующем приложении. Для сканирования репозиториев включите приложение FixVibe GitHub. Соберите находки — секреты, RLS, авторизация, заголовки, сторонние.
2. Усильте защиту: Исправьте находки с высокой уверенностью. Включите RLS + FORCE. Переместите секреты в переменные окружения. Установите CSP и HSTS в middleware. Используйте проверку аутентификации на стороне сервера. Применяйте промпт coding-агента только там, где применимы изменения кода/конфигурации, а для исправлений DNS или со стороны провайдера следуйте шагам оператора.
3. Monitor: Запланируйте ежедневное пассивное сканирование или еженедельное активное сканирование проверенного домена. Настройте вебхуки для Slack. Каждое критическое обнаружение должно вызывать тревогу в течение нескольких минут после прибытия корабля.
4. Реагируйте: Когда появляется находка, скопируйте действие по устранению FixVibe, соответствующее ответственному за исправление: промпт coding-агента для работы с кодом/конфигурацией или шаги оператора для DNS, консоли провайдера, ротации секретов и ручной проверки. Запустите повторное сканирование для подтверждения.

Куда движется поле

Устранение этих пробелов — задача сегодняшних команд. В течение следующих 2-3 лет граница сдвинется: лучшие настройки по умолчанию в средах и инструментах (Next.js промежуточное программное обеспечение auto-CSP, Supabase RLS по умолчанию), IDE-time обратная связь по безопасности (Cursor предлагает предупреждения, когда вы собираетесь вставить сервисный ключ в клиентский компонент) и MCP-управляемое автоисправление (ваш агент кодирования имеет доступ к выводам FixVibe и может исправить их автономно). Паблик FixVibe changelog отслеживает, какие пробелы закрываются первыми.

Следующие шаги

Контрольный список go/no-go перед запуском см. в разделе Pre-launch SaaS security checklist. Пошаговое руководство по усилению защиты с фрагментами кода и реальными шаблонами ошибок можно найти в How to secure an app built with AI coding tools.