Главные уязвимости ИИ-кода: чек-лист и промпты для их закрытия

Разбор 5 критических уязвимостей, которые регулярно допускают ИИ-агенты (Cursor, Claude Code, Devin, Replit, Lovable), и готовые инструкции по их устранению. Материал предназначен для предпринимателей и разработчиков, запускающих сервисы с помощью нейросетей.

1. Защита от атаки SSRF при загрузке файлов

ИИ-агенты по умолчанию используют функции вроде fetch(userUrl) без валидации адреса. Это позволяет злоумышленнику заставить сервер обратиться к внутренним сервисам и прочитать закрытые ключи доступа.

1. Открой файл, обрабатывающий внешние ссылки (например, upload.js или api/fetch-image.ts).
2. Найди вызов сетевого запроса к стороннему URL.
3. Вставь перед запросом валидацию схемы и IP-адресов или передай ИИ-агенту промпт для автоматического исправления:

Проверь все функции, выполняющие HTTP-запросы по пользовательским URL. Реализуй строгую валидацию: разрешай запросы только по схемам http/https, блокируй обращения к приватным IP-адресам (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.1) и к метаданным облачных провайдеров (169.254.169.254).

2. Проверка прав доступа к объектам (защита от IDOR)

Нейросети часто ограничиваются проверкой факта входа пользователя, но не проверяют, принадлежит ли конкретный заказ или файл именно ему. Изменение номера в адресной строке браузера (с /orders/125 на /orders/126) раскрывает чужие данные.

1. Перейди в файл контроллера или API-роута (например, src/routes/orders.js).
2. Найди строку получения объекта из базы данных по его ID.
3. Убедись, что запрос к базе содержит фильтр по ID текущего авторизованного пользователя (where: { id: orderId, userId: currentUser.id }).
4. Скопируй промпт для исправления авторизации во всем проекте:

Найди все API-эндпоинты, принимающие идентификатор ресурса в параметрах (ID заказа, профиля, документа). Добавь явную проверку владения ресурсом: сервер должен сверять owner_id объекта с id авторизованного пользователя из JWT или сессии и возвращать ошибку 403 при несоответствии.

3. Настройка Row Level Security (RLS) в Supabase и Lovable

В конструкторах и визуальных средах ИИ-агент создаёт таблицы, но часто оставляет их открытыми для прямого чтения и записи через клиентский API.

1. Открой панель управления базы данных Supabase и перейди в раздел Table Editor.
2. В списке таблиц обрати внимание на статусы: при отсутствии защиты отображается предупреждение RLS Disabled.
3. Перейди в раздел SQL Editor, создай новый запрос и вставь шаблон политики безопасности:

-- Включение RLS для таблицы заказов
ALTER TABLE public.orders ENABLE ROW LEVEL SECURITY;

-- Пользователь видит только свои записи
CREATE POLICY "Users can read own orders" ON public.orders
FOR SELECT USING (auth.uid() = user_id);

-- Пользователь создает записи только со своим user_id
CREATE POLICY "Users can insert own orders" ON public.orders
FOR INSERT WITH CHECK (auth.uid() = user_id);

4. Ограничение попыток входа (Rate Limiting)

Нейросети практически никогда не добавляют лимиты на количество попыток входа. В результате панель управления становится уязвима к подбору паролей (брутфорсу).

1. Открой файл маршрутов авторизации (например, src/routes/auth.js).
2. Найди эндпоинт обработки формы входа (/api/login).
3. Скопируй и отправь ИИ-агенту промпт для подключения защиты:

Добавь rate-limiting на все эндпоинты авторизации, сброса пароля и админ-панели. Настрой ограничение: не более 5 неудачных попыток входа с одного IP-адреса в течение 15 минут. При превышении лимита возвращай статус 429 Too Many Requests.

5. Проверка граничных условий и бизнес-логики

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

1. Открой файл обработки корзины или оформления заказа (src/services/checkout.js).
2. Проверь блоки вычисления итоговой стоимости и количества позиций.
3. Передай нейросети следующий промпт для закрытия логических дыр:

Проведи аудит бизнес-логики в проекте. Убедись, что все входящие числовые параметры (количество товаров, сумма, баланс) строгой валидацией проверяются на стороне сервера: value > 0. Добавь валидацию схемы через Zod или Joi на всех API-эндпоинтах.

Лимиты и нюансы

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

Исследование компании Tenzai (исходный набор данных опубликован в репозитории TenzaiLabs/datasets) зафиксировало 69 уязвимостей в 15 приложениях, созданных популярными агентами. Чаще всего проваливаются разграничение прав доступа, проверка внешних URL и защита от перебора паролей.

Типичные ошибки при работе с ИИ-кодерами:

• Доверие дефолтным настройкам таблиц в no-code / low-code инструментах.
• Отсутствие единого файла с правилами безопасности (.cursorrules или prompt.md) в корне проекта.
• Расчет на то, что нейросеть сама предусмотрит нештатные сценарии бизнес-логики.

Что дальше

Чтобы уязвимости не попадали в продакшен, внедри эти промпты и правила в регулярный регламент разработки твоего проекта. Если ты хочешь построить надежную ИИ-систему с автоматической проверкой кода и интеграцией под задачи бизнеса, это можно реализовать вместе с нами. Напиши в директ @ii.systema слово система, и мы обсудим детали.