AI-агенты для написания кода создают логику авторизации, которая компилируется, проходит проверку и при этом реализует неверные политики безопасности. Нарушение контроля доступа занимает первое место в OWASP Top 10:2025, где 100% протестированных приложений показали наличие той или иной формы этой уязвимости, что в сумме составило 1 839 701 зафиксированный случай — самый высокий показатель среди всех категорий в списке.
Часть этой категории также относится к той области, для которой сканирование на основе шаблонов никогда не предназначалось. Когда агент пропускает проверку прав владения, нарушенное правило относится к самому приложению, а не к базе данных сигнатур. В результате не существует известного «плохого» шаблона, с которым можно было бы сравнить код.
Что такое нарушение контроля доступа?
Нарушение контроля доступа — это неспособность обеспечить соблюдение прав аутентифицированного пользователя на выполнение действий или просмотр данных. Пользователь подтверждает свою личность, а приложение затем предоставляет ему данные или действия, принадлежащие кому-то другому. Два конкретных случая составляют большую часть того, с чем сталкиваются команды.
1. BOLA: нарушение авторизации на уровне объекта
BOLA — это неспособность проверить, имеет ли запрашивающий право на конкретный объект, который он запросил. Она занимает первое место в OWASP API Security Top 10, что ставит её во главу обоих списков OWASP, применимых к современным приложениям.
2. IDOR: небезопасная прямая ссылка на объект
IDOR — это та же самая ошибка, рассматриваемая со стороны злоумышленника. Приложение раскрывает внутренний идентификатор, например ID записи, и подстановка другого значения возвращает данные, принадлежащие другой учетной записи. Одна ошибка обычно является одновременно и BOLA, и IDOR.
OWASP переместила эту категорию на вершину своего списка в 2021 году, и она оставалась там вплоть до редакции 2025 года. Это простые уязвимости. Они удерживают свои позиции, потому что их легко допустить, трудно обнаружить автоматически, и они сразу же приносят выгоду после обнаружения.
Почему AI-агенты так часто ошибаются в авторизации?
Разработка программного обеспечения стала агентной, а безопасность — нет. Безопасность приложений строилась вокруг сканирования, которое сопоставляет известные плохие шаблоны и передает результаты людям, знающим правила продукта. Когда агент пишет эндпоинт, никто в процессе разработки по умолчанию не придерживается этих правил, и у возникающей ошибки нет шаблона для сопоставления. Чтобы устранить этот пробел, недостаточно просто добавить еще одно правило.
Потому что требование авторизации никогда не было сформулировано, а агент не ошибается относительно поставленной ему задачи. Представьте разработчика, который просит AI-агента добавить эндпоинт, возвращающий счет по ID. Агент создает маршрут, который проверяет, вошел ли пользователь в систему, ищет счет по идентификатору из URL, возвращает 404, если ничего не найдено, и отправляет запись клиенту.
Каждое из этих решений является правильным для поставленной задачи. Эндпоинт выполняет аутентификацию, обрабатывает случай отсутствия записи и выглядит чисто при проверке. Но он также позволяет любому аутентифицированному пользователю прочитать любой счет в системе, изменив одно значение в URL.
Исправление заключается в одном дополнительном условии при поиске: сопоставить счет не только по его идентификатору, но и по организации, к которой принадлежит вызывающий пользователь. Больше ничего в эндпоинте менять не нужно.
Почему исправление невозможно определить только по коду
Чтобы понять, что вторая версия правильна, нужно знать три факта, которые нигде не отражены в генерируемом коде:
- Счета принадлежат организациям.
Счета принадлежат организациям.
- Доступ пользователя ограничен организациями, в которых он состоит.
Доступ пользователя ограничен организациями, в которых он состоит.
- Чтение данных между организациями в этом продукте никогда не является легитимным.
Чтение данных между организациями в этом продукте никогда не является легитимным.
В другом продукте третий факт может быть ложным, поскольку некоторые платформы по своей архитектуре позволяют аудиторам, реселлерам или родительским аккаунтам просматривать данные через границы арендаторов (tenants). Это правило является свойством продукта, а не языка или фреймворка. Оно живет в модели данных, в решении, принятом два года назад, и в головах инженеров, которые его приняли.
Что должен проверять рецензент
Разработчик-человек в такой команде обычно замечает это по одной причине: он знает продукт. Агент, работающий на основе промпта и окружающего файла, не имеет доступа к тому, что делает эту проверку необходимой.
Стоит обратить внимание на две детали при проверке. Первая — код ответа. Включение условия владения в поиск означает, что запрос счета другой организации вернет ту же ошибку 404, что и запрос несуществующего счета. Это именно то поведение, которое вам нужно, поскольку код 403 подтвердил бы существование записи и позволил бы злоумышленнику перебирать валидные идентификаторы. Вторая — что именно возвращается. Возврат сохраненной записи без изменений отправляет все её поля, поэтому один и тот же обработчик часто несет в себе проблему раскрытия данных наряду с проблемой авторизации.
Могут ли инструменты SAST находить нарушения контроля доступа?
Для классов уязвимостей, имеющих шаблон, задача обнаружения в значительной степени решена. Авторизация — это исключение, и она находится именно там, где AI-сгенерированный код наиболее слаб. Статический анализ отслеживает описываемую форму, а авторизация на уровне объектов её не имеет.
Возьмем для контраста инъекцию: уязвимость типа инъекции имеет форму, которую можно описать: недоверенные входные данные достигают опасного приемника (sink), не проходя через санитацию. Эта форма становится правилом, и движок отслеживает данные от источника до приемника, сообщая о каждом совпадающем пути.
Что статический анализ покрывает в рамках нарушения контроля доступа
Нарушение контроля доступа — самая большая категория в OWASP Top 10, и не вся она устойчива к сканированию. A01:2025 сопоставляет 40 CWE, и некоторые из них имеют именно ту отслеживаемую форму, с которой хорошо справляется статический анализ, включая обход пути (path traversal), открытый редирект и подделку запросов на стороне сервера (SSRF). Современные семантические движки выходят за рамки сопоставления сигнатур, моделируя потоки данных и намерения кода, и могут сигнализировать о структурном отсутствии декоратора авторизации или промежуточного ПО на маршруте, если кодовая база следует последовательной конвенции.
Где проходит граница покрытия
Часть, которая сопротивляется анализу, более узкая. Это авторизация на уровне объектов, классифицируемая как CWE-639 (обход авторизации через контролируемый пользователем ключ), CWE-862 (отсутствие авторизации) и CWE-863 (некорректная авторизация). Здесь не вызывается ничего опасного, никакое недоверенное значение не попадает туда, куда не следует, и каждая строка кода идиоматична. Дефект заключается в отсутствии сравнения, которое требуют только собственные правила приложения.
Чтобы пометить это, движок должен знать, какие поля представляют владение в этой схеме, какие вызывающие стороны имеют разрешение и где проходит граница между арендаторами. Ничто из этого не является вопросом качества правила. Это информация, которой нет внутри сканируемого файла.
Детерминированные движки и логический вывод должны дополнять друг друга, а не конкурировать. Движки каждый раз возвращают один и тот же результат для классов, которые они покрывают, что позволяет команде использовать их как фильтр в пайплайне. Авторизация на уровне объектов лежит вне того, что может описать правило, поэтому для её решения требуется другой инструмент.
Как найти ошибки, у которых нет шаблона?
Вы можете находить ошибки, у которых нет шаблона, рассуждая на основе модели приложения, а не на основе файла перед вами.
Для поиска ошибки в обработке счетов требуются четыре факта: что вызывает этот эндпоинт, к какому объекту относится запрашиваемый ресурс, какие пользователи имеют к нему доступ и где проходит граница доверия между тенантами. Эти факты можно извлечь из кодовой базы, схемы и того, что запущенно в продакшене, но их необходимо объединить в нечто, доступное для анализа. Snyk называет эту собранную модель графом контекста приложения (application-context graph): архитектура, потоки данных, классификация данных, границы доверия и реальное состояние продакшена, построенные один раз и обновляемые по мере изменения кода. Когда такая модель создается, отсутствие проверки прав доступа становится очевидным, поскольку анализ может сравнить то, что проверяет эндпоинт, с тем, что требуют собственные правила приложения.
Три условия делают результат заслуживающим доверия.
- Рассуждения должны опираться на эту модель. Без нее передовые методы логического вывода выдают правдоподобные результаты о частично вымышленной кодовой базе и попусту тратят токены на слепое сканирование.
Рассуждения должны опираться на эту модель. Без нее передовые методы логического вывода выдают правдоподобные результаты о частично вымышленной кодовой базе и попусту тратят токены на слепое сканирование.
- Результаты должны быть подтверждены тем, что их не создавало. Нельзя доверять агенту, нашедшему уязвимость, проверять собственное исправление, а система, которая оценивает собственный вывод, переносит в будущее все то, что упустил ее анализ.
Результаты должны быть подтверждены тем, что их не создавало. Нельзя доверять агенту, нашедшему уязвимость, проверять собственное исправление, а система, которая оценивает собственный вывод, переносит в будущее все то, что упустил ее анализ.
- Исправление должно быть доказанным, а не просто предложенным. Однострочная поправка должна быть проверена на соответствие правилам приложения и оставаться эффективной при изменении кода. Находка, которая так и не превратилась в объединенный (merged) фикс, оставляет эндпоинт ровно в том же уязвимом состоянии, в каком он был.
Исправление должно быть доказанным, а не просто предложенным. Однострочная поправка должна быть проверена на соответствие правилам приложения и оставаться эффективной при изменении кода. Находка, которая так и не превратилась в объединенный (merged) фикс, оставляет эндпоинт ровно в том же уязвимом состоянии, в каком он был.
Анализ собранного приложения в сочетании с работающими параллельно детерминированными механизмами — это направление, в котором Snyk развивает решение Evo Agentic AppSec, впервые представленное в августе. Тестирование во время выполнения затем подтверждает, к чему именно может получить доступ злоумышленник — именно здесь сегодня применяется Evo Continuous Offensive Security.
Что вашей команде следует предпринять в связи с этим прямо сейчас?
Пять шагов, для начала которых не требуется никаких новых инструментов.
- Составьте инвентаризационный список эндпоинтов, принимающих идентификатор объекта из запроса. Каждый маршрут, извлекающий ID, имя файла или ключ из URL или тела запроса, является кандидатом. Этот список обычно короче, чем ожидает команда, и длиннее, чем она надеется.
Составьте инвентаризационный список эндпоинтов, принимающих идентификатор объекта из запроса. Каждый маршрут, извлекающий ID, имя файла или ключ из URL или тела запроса, является кандидатом. Этот список обычно короче, чем ожидает команда, и длиннее, чем она надеется.
- Запишите правила контроля доступа. Для каждого типа ресурса зафиксируйте, кому он принадлежит и кто может его читать или изменять. Ошибки авторизации проходят проверки потому, что эта информация никогда нигде не записывалась в виде, доступном для проверки рецензентом или аналитиком.
Запишите правила контроля доступа. Для каждого типа ресурса зафиксируйте, кому он принадлежит и кто может его читать или изменять. Ошибки авторизации проходят проверки потому, что эта информация никогда нигде не записывалась в виде, доступном для проверки рецензентом или аналитиком.
- Сделайте авторизацию обязательным пунктом проверки в пулл-реквестах, созданных агентами. Это не общее указание проверять внимательно, а конкретный вопрос: проверяет ли данный эндпоинт, что вызывающая сторона имеет право доступа к объекту, и по какому именно полю?
Сделайте авторизацию обязательным пунктом проверки в пулл-реквестах, созданных агентами. Это не общее указание проверять внимательно, а конкретный вопрос: проверяет ли данный эндпоинт, что вызывающая сторона имеет право доступа к объекту, и по какому именно полю?
- Добавьте межтенантый тест для каждого типа ресурса. Рекомендации OWASP по предотвращению уязвимостей говорят об этом прямо: разработчики и специалисты по обеспечению качества должны включать функциональный контроль доступа в свои модульные и интеграционные тесты. Один тест на ресурс, подтверждающий, что валидная сессия от одного тенанта получает ошибку 404 при запросе объекта другого тенанта, превращает правило, записанное вами на втором шаге, в непрерывно соблюдаемое требование.
Добавьте межтенантый тест для каждого типа ресурса. Рекомендации OWASP по предотвращению уязвимостей говорят об этом прямо: разработчики и специалисты по обеспечению качества должны включать функциональный контроль доступа в свои модульные и интеграционные тесты. Один тест на ресурс, подтверждающий, что валидная сессия от одного тенанта получает ошибку 404 при запросе объекта другого тенанта, превращает правило, записанное вами на втором шаге, в непрерывно соблюдаемое требование.
- Регулярно выполняйте глубокий анализ всей кодовой базы. Точка контроля разделилась на три части: в реальном времени внутри внутреннего цикла агента, быстрые детерминированные сканирования при каждом изменении в CI и глубокий контекстный анализ всей кодовой базы. Ошибки авторизации на уровне объектов всплывают в последнем случае.
Регулярно выполняйте глубокий анализ всей кодовой базы. Точка контроля разделилась на три части: в реальном времени внутри внутреннего цикла агента, быстрые детерминированные сканирования при каждом изменении в CI и глубокий контекстный анализ всей кодовой базы. Ошибки авторизации на уровне объектов всплывают в последнем случае.
Какие из ваших эндпоинтов не прошли бы этот межтенантный тест уже сегодня? Начните с инвентаризации на первом шаге. Чтобы узнать, куда Snyk ведет развитие агентской безопасности приложений, прочитайте материал «A First Look at Evo Agentic AppSec».
ЗАПИСАТЬСЯ НА ЖИВУЮ ДЕМОНСТРАЦИЮ
Безопасное внедрение ИИ в масштабах предприятия
Evo помогает организациям безопасно внедрять ИИ и масштабировать его использование, обеспечивая прозрачность, управление и безопасность во всем, что касается разработки на основе ИИ и самих ИИ-приложений.
