Исследование показало, что код, созданный с помощью ИИ, в 1,7 раза чаще содержит серьёзные проблемы и в 2,74 раза более подвержен уязвимостям безопасности, чем код, написанный человеком. Если вы что-то создавали с помощью Cursor, Claude Code или GitHub Copilot, в вашем проекте, вероятно, есть хотя бы одна из пяти наиболее распространённых проблем безопасности. Вот что это такое и как их найти.

Ключевые факты
  • 45% кода, созданного ИИ, содержит хотя бы одну уязвимость безопасности
  • 1,7x выше вероятность серьёзных проблем по сравнению с кодом, написанным человеком
  • 2,74x выше подверженность уязвимостям безопасности
  • Наиболее частые: API-ключи в коде, отсутствие проверки входных данных, отсутствие защиты на уровне строк
  • Время на аудит: 2-3 часа для типичного проекта
  • Последняя проверка: апрель 2026

Почему код ИИ уязвим

Инструменты ИИ для написания кода оптимизированы под «работает ли это?», а не под «это безопасно?». Когда вы просите Cursor «добавить аутентификацию пользователя», он генерирует код, который аутентифицирует пользователей. Он автоматически не добавляет ограничение частоты запросов, санитизацию входных данных, защиту от CSRF или безопасное управление сессиями — потому что вы об этом не просили.

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

5 наиболее распространённых уязвимостей

1. API-ключи, встроенные в код фронтенда. ИИ часто размещает API-ключи прямо в клиентском JavaScript или компонентах React. Любой может открыть DevTools браузера и увидеть их. Решение: переместите все ключи в переменные окружения (файлы .env) и получайте к ним доступ только на стороне сервера. Время: 15 минут.

2. Отсутствие защиты на уровне строк в базах данных. Если вы используете Supabase (частое явление при быстрой разработке), код, созданный ИИ, часто даёт каждому аутентифицированному пользователю доступ к данным всех остальных пользователей. Решение: включите Row Level Security и добавьте политики для каждого пользователя. Время: 30 минут.

3. Отсутствие проверки входных данных на стороне сервера. Формы принимают всё — скрипты, перегруженные полезные нагрузки, попытки SQL-инъекций. ИИ добавляет проверку на стороне клиента (которую пользователи могут обойти), но пропускает проверку на стороне сервера. Решение: добавьте схемы Zod или аналогичную проверку на каждой конечной точке API. Время: 30 минут на конечную точку.

4. Отсутствие ограничения частоты запросов. Любой может попадать в ваш API 1000 раз в секунду. Нет регулирования, нет защиты от злоупотреблений. Решение: добавьте ограничение частоты запросов через Upstash Redis или аналогичное. Время: 20 минут.

5. Незащищённые маршруты. Страницы панели управления, админ-панели и конечные точки данных пользователей загружаются без проверки, вошёл ли пользователь в систему. Решение: добавьте middleware аутентификации на каждый защищённый маршрут. Время: 15 минут.

Находите это полезным? Мы публикуем руководства по безопасности для проектов на основе ИИ каждую неделю. Присоединяйтесь к читателям, которые разрабатывают безопасно →

Как провести аудит вашего проекта

Проверьте этот список для любого проекта, созданного с помощью инструментов ИИ для написания кода:

Найдите все встроенные ключи в вашей кодовой базе. Выполните: grep -r "sk-" . && grep -r "api_key" . && grep -r "secret" . в директории вашего проекта. Любые совпадения в файлах фронтенда — критические уязвимости.

Проверьте каждую конечную точку API на проверку входных данных. Откройте каждый файл маршрута API. Если он напрямую использует req.body без проверки, это уязвимо.

Проверьте безопасность базы данных. Если используете Supabase, откройте вкладку Authentication → Policies. Если нет политик RLS, каждый пользователь может видеть данные всех остальных пользователей.

Протестируйте аутентификацию на каждой странице. Откройте браузер в режиме инкогнито (без входа) и перейдите на каждую страницу в вашем приложении. Если загружается какая-либо страница панели управления или страница, специфичная для пользователя, этот маршрут не защищён.

Проверьте наличие ограничения частоты запросов. Попробуйте обратиться к конечной точке API 100 раз подряд, используя простой скрипт. Если все 100 запросов успешны, у вас нет ограничения частоты запросов.

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

Изменение мышления

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

Наш Prompt Optimizer может помочь вам автоматически добавлять эти спецификации безопасности к любому запросу для написания кода.

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

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