Безопасность AI-кода: 10 уязвимостей, которые AI создаёт чаще всего

AI-ассистенты генерируют код быстрее, чем любой разработчик. Но скорость имеет цену: согласно исследованию Stanford University, 45% кода, сгенерированного AI-моделями, содержит хотя бы одну уязвимость безопасности. Это не значит, что AI плохой инструмент. Это значит, что без понимания типичных проблем вы рискуете выкатить в продакшн приложение с дырами, которые найдёт первый же бот-сканер.

Модели обучены на миллиардах строк открытого кода. Проблема в том, что значительная часть этого кода — учебные примеры, Stack Overflow ответы и legacy-проекты, где безопасность не была приоритетом. Когда вы просите AI «написать авторизацию», он выдаёт рабочий код — но часто без валидации входных данных, без rate limiting, без защиты от timing-атак.

Исследование CodeRabbit (2025) показало, что код, сгенерированный AI без дополнительных инструкций по безопасности, содержит в 2.74 раза больше уязвимостей, чем код, написанный вручную опытным разработчиком. При этом 72% разработчиков в опросе GitHub признались, что принимают AI-сгенерированный код без тщательной проверки безопасности.

OWASP (Open Web Application Security Project) поддерживает список десяти самых критичных уязвимостей веб-приложений. Давайте разберём, как AI-генерация усугубляет каждую из них.

1. Broken Access Control (Нарушение контроля доступа)

AI часто создаёт API-эндпоинты без проверки авторизации. Вы просите «создай CRUD для пользователей» — получаете маршруты, где любой может удалить чужой аккаунт, просто подставив другой ID в URL. Модель генерирует функциональный код, но не думает о том, кто имеет право вызывать каждый эндпоинт.

2. Cryptographic Failures (Криптографические ошибки)

AI может предложить MD5 для хеширования паролей, использовать ECB-режим шифрования или хранить JWT-секреты прямо в коде. Модели часто генерируют «рабочую» криптографию, которая на практике не обеспечивает никакой защиты. Bcrypt с правильным salt-раундом? Только если вы явно попросите.

3. Injection (Инъекции)

SQL-инъекции — классика, которую AI воспроизводит регулярно. Строковая конкатенация вместо параметризованных запросов, отсутствие экранирования в ORM-запросах, конкатенация пользовательского ввода в shell-команды. AI часто демонстрирует самый простой путь — а самый простой путь обычно самый опасный.

4. Insecure Design (Небезопасное проектирование)

AI не мыслит архитектурно о безопасности. Он не добавит rate limiting к форме логина, не подумает о CSRF-токенах, не предложит разделить базу данных на read/write реплики для изоляции. Это уровень решений, который требует понимания threat model — чего у AI нет.

5. Security Misconfiguration (Неправильная конфигурация)

CORS с wildcard (*), debug-режим в продакшне, открытые порты баз данных, дефолтные пароли в конфигах — AI генерирует конфигурации «чтобы работало», а не «чтобы было безопасно». Особенно часто это проявляется в Docker-файлах и конфигурациях nginx.

6. Vulnerable Components (Уязвимые компоненты)

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

7. Authentication Failures (Ошибки аутентификации)

Слабая валидация паролей, отсутствие MFA, токены без expiration, сессии без инвалидации при смене пароля. AI создаёт «happy path» авторизации, но не продумывает edge cases: что если пользователь меняет пароль с другого устройства? Что если токен украден?

8. Data Integrity Failures (Нарушение целостности данных)

Десериализация без валидации, отсутствие проверки подписей, принятие данных от клиента без верификации на сервере. AI часто генерирует код, который доверяет входным данным — потому что в учебных примерах это упрощение встречается повсюду.

9. Logging & Monitoring Failures (Отсутствие логирования)

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

10. Server-Side Request Forgery (SSRF)

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

Hardcoded Secrets (Захардкоженные секреты)

Это проблема номер один в AI-коде. Модели регулярно вставляют API-ключи, пароли баз данных и секретные токены прямо в исходный код. «Для примера» — говорит AI. А разработчик забывает заменить их на переменные окружения и пушит в открытый репозиторий. Сканеры GitHub находят тысячи таких утечек ежедневно.

XSS через динамический контент

React защищает от XSS по умолчанию, но AI часто генерирует dangerouslySetInnerHTML для «гибкости». В Vue — v-html. В чистом JS — innerHTML. Каждый такой случай — потенциальная XSS-уязвимость, если данные приходят от пользователя.

Открытые эндпоинты и отсутствие middleware

AI создаёт маршруты, которые работают. Но часто забывает обернуть их в middleware авторизации. В Express.js или Next.js API routes это означает, что любой может вызвать внутренний API, зная URL. Без rate limiting это ещё и вектор для DDoS.

Используйте этот чеклист каждый раз, когда принимаете код от AI-ассистента. Это не параноидальность — это инженерная дисциплина.

• Проверьте все строковые литералы на наличие секретов, ключей и паролей. Замените на process.env.
• Убедитесь, что SQL-запросы используют параметризацию, а не строковую конкатенацию.
• Проверьте CORS-настройки: никаких wildcard (*) в продакшне.
• Каждый API-эндпоинт должен иметь middleware авторизации.
• Rate limiting на все публичные эндпоинты (login, register, API).
• Пароли хешируются bcrypt/scrypt/argon2, никакого MD5/SHA1.
• JWT-токены имеют разумный expiration (15 мин для access, 7 дней для refresh).
• Нет dangerouslySetInnerHTML, v-html или innerHTML с пользовательскими данными.
• Все зависимости проверены через npm audit / snyk.
• Логирование security-событий: логин, смена пароля, неудачные попытки.
• Input validation на сервере — клиентская валидация не считается.
• HTTPS everywhere, HSTS headers, secure cookie flags.

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

Шаг 1: Статический анализ

Запустите ESLint с плагинами безопасности (eslint-plugin-security, eslint-plugin-no-secrets). Это автоматически поймает hardcoded секреты, eval(), небезопасные регулярки и другие паттерны.

Шаг 2: Dependency audit

npm audit, Snyk или Dependabot — выберите любой инструмент, но запускайте его при каждом добавлении зависимости. AI может предложить пакет с известной уязвимостью.

Шаг 3: Ревью security-критичного кода

Auth, payments, file uploads, admin endpoints — эти части всегда проверяются вручную. AI может помочь написать черновик, но финальное решение о безопасности принимает человек.

Шаг 4: Тестирование

Напишите тесты на негативные сценарии: попытка доступа без токена, SQL-инъекция в поисковую строку, XSS в форме комментария. AI отлично справляется с генерацией таких тестов — используйте его для этого.

Самый эффективный способ получить безопасный код от AI — включить безопасность в промпт. Вместо «напиши авторизацию» скажите «напиши авторизацию с bcrypt хешированием, JWT с 15-минутным expiration, rate limiting 5 попыток в минуту, audit logging всех событий, CSRF protection». Чем конкретнее требования — тем безопаснее результат.

В BRIQ.TEAM мы учим этому подходу с первого дня: security не добавляется после, она закладывается в промпт. Каждый проект курса включает security review как обязательный этап.

• Semgrep — статический анализ с правилами для AI-кода
• CodeRabbit — AI-ревьюер, который находит уязвимости в PR
• Snyk — проверка зависимостей и контейнеров
• GitGuardian — обнаружение утечек секретов в коде
• OWASP ZAP — динамическое тестирование веб-приложений
• Trivy — сканирование Docker-образов

AI-генерация кода — это суперсила, но как любая суперсила, она требует ответственности. 45% уязвимостей — это не приговор, а точка роста. Разработчик, который понимает типичные уязвимости AI-кода и умеет их находить, ценнее того, кто просто копирует вывод модели.

Безопасность — это не отдельный навык. Это часть инженерной культуры. И в эпоху AI-разработки эта часть становится только важнее.