Ошибки доступа в коде, написанном ИИ: почему это опаснее обычных багов

Вы получили PR от AI-ассистента. Синтаксис чистый, тесты зелёные, линтер молчит. Но именно в этот момент стоит быть особенно осторожными.

Код работает — значит ли это, что он безопасен?

Весной 2025 года Андрей Карпати ввёл термин «vibe coding» — разработка, при которой разработчик формулирует намерение на естественном языке, а AI пишет код [5]. К марту 2025 года 25% стартапов из зимнего батча Y Combinator имели кодовую базу, написанную ИИ на 95% [5]. Это уже не эксперимент — это стандартная практика.

Проблема не в том, что AI пишет плохой код в привычном смысле. Проблема в том, что AI пишет код, который _работает_, но не _безопасен_. А ошибки контроля доступа — особый класс дефектов, который эта разница делает особенно опасным.

Эта статья адресована CTO, VP Engineering, Tech Lead и AppSec-специалистам — тем, кто принимает решения о том, как AI-код попадает в продакшен и что стоит между строчкой сгенерированного кода и работающим сервисом.

Что такое ошибки доступа и почему они на первом месте уже пятый год подряд

Broken access control (нарушение контроля доступа) — это ситуация, когда приложение не проверяет должным образом, имеет ли конкретный пользователь право выполнить конкретное действие с конкретным ресурсом.

OWASP фиксирует несколько устойчивых подтипов [1]:

• IDOR (Insecure Direct Object Reference) — доступ к чужим объектам через прямую манипуляцию идентификаторами: например, /api/orders/1234 → /api/orders/1235 без проверки владельца.
• Вертикальное повышение привилегий — обычный пользователь получает доступ к функциям администратора.
• Горизонтальное повышение привилегий — пользователь A получает доступ к данным пользователя B.
• Пропущенный контроль на уровне функций — API-эндпоинт доступен всем аутентифицированным пользователям, хотя должен требовать роли.
• Клиентская авторизация — проверка прав только на фронтенде без серверного контроля.

Согласно данным OWASP, эта категория присутствует в 94% протестированных приложений [6]. В обновлённом OWASP Top 10 2025 года broken access control остаётся на первом месте — при этом SSRF теперь включена в эту же категорию [7].

Для понимания масштаба: Instagram в своё время имел IDOR в API, позволявший читать приватные посты и сообщения по одному лишь user_id [8]. Optus в 2023 году потерял персональные данные почти 10 миллионов клиентов через аналогичную уязвимость [8]. Это не экзотика — это базовый дефект, который возникает, когда разработчик думает «аутентификация есть — значит, всё хорошо», не проверяя авторизацию на уровне каждого объекта.

Почему исправить это так тяжело? Потому что broken access control — это не баг реализации. Это архитектурный и логический дефект. Нельзя написать правило в линтере, которое поймает «этот эндпоинт должен требовать роль admin, а не просто аутентификацию». Это требует понимания предметной области.

Почему AI порождает их системно и в промышленных масштабах

Модель не понимает контекст доверия

Большие языковые модели обучены на миллиардах строк публичного кода — GitHub, Stack Overflow, документация [9]. Значительная часть этого кода исторически небезопасна: там заложены паттерны из эпохи, когда access control не был приоритетом. Модели воспроизводят эти паттерны — не потому что они «хотят» создать уязвимость, а потому что статистически именно так выглядит большинство примеров в их обучающей выборке.

Но есть более глубокая проблема. AI не знает, кто такой «администратор» в контексте _вашей_ системы. Он не знает, что заказ принадлежит конкретному пользователю. Он не знает бизнес-правила: «менеджер может видеть данные своей команды, но не других команд». Он генерирует технически корректный код без семантического контекста.

Исследование Tenzai (декабрь 2025) протестировало пять ИИ-платформ — Claude Code, Cursor, Windsurf, Replit, Devin — через одинаковые промпты на 15 приложениях. Результат: 69 уязвимостей, из которых шесть критических. Доминирующий класс — ошибки бизнес-логики и авторизации, а не инъекции или XSS [4]. AI-инструменты научились избегать SQL-инъекций. Они корректно экранируют вывод. Но они не справляются с контекстно-зависимыми решениями: должен ли этот пользователь видеть этот ресурс?

Вот конкретный паттерн, который воспроизводит AI: генерация обработчика admin-роута с проверкой аутентификации, но без проверки авторизации. Код проверяет, что вы залогинены. Он не проверяет, что вы должны иметь права администратора. Любой аутентифицированный пользователь получает доступ к admin-функциям [3].

Данные: масштаб проблемы в цифрах

Исследование Apiiro, охватившее десятки тысяч репозиториев и тысячи разработчиков из компаний Fortune 50, зафиксировало [2]:

• рост путей к повышению привилегий на 322% в командах, использующих AI-ассистентов;
• рост архитектурных дефектов дизайна на 153%;
• рост экспозиции секретов на 40%;
• при этом синтаксические ошибки снизились на 76%, логические баги — на 60%.

Как сформулировал Apiiro: «AI исправляет опечатки, но создаёт бомбы замедленного действия» [2].

Veracode в своём отчёте 2025 GenAI Code Security Report, охватившем более 100 языковых моделей и 80 задач на четырёх языках, обнаружила, что 45% AI-кода содержит уязвимости из OWASP Top 10 [10]. При этом более новые и крупные модели не показали значимого улучшения по безопасности — паттерн устойчив к масштабированию.

Отдельный результат Apiiro: к июню 2025 года AI-код добавлял более 10 000 новых security findings в месяц в исследованных репозиториях — рост в 10 раз по сравнению с декабрём 2024 года [2].

Почему это именно архитектурный, а не обычный баг

Традиционное деление важно для понимания стоимости: баг реализации (хардкоженный секрет, SQL-инъекция) исправляется за минуты. Дефект авторизации на архитектурном уровне — за недели. Он затрагивает несколько слоёв системы: схему данных, API-контракты, middleware, бизнес-логику [3].

Разработчики Veracode прямо указывают: для контекстно-зависимых уязвимостей вроде XSS у LLM лишь 12-13% кода оказывается безопасным, потому что защита требует понимания всего контекста приложения, а не только конкретного фрагмента [10]. Аналогично работают ошибки доступа: правильный контроль требует знания всей системы привилегий, а не только текущей функции.

IBM в отчёте Cost of a Data Breach 2025 зафиксировала, что 97% организаций сообщили об AI-related security incident [11]. Это не говорит о том, что все инциденты вызваны broken access control — но в совокупности с данными Apiiro и Veracode рисует системную картину.

Как это выглядит в реальных инцидентах 2025 года

Lovable и CVE-2025-48757: 170 приложений с инвертированным контролем доступа

Уязвимость CVE-2025-48757 в платформе Lovable (vibe coding) показала структурный изъян: Row Level Security политики в Supabase генерировались некорректно, что в ряде случаев позволяло удалённым пользователям без аутентификации читать и писать в произвольные таблицы [12]. Исследователи зафиксировали более 170 продакшен-приложений с нарушенной логикой доступа [13].

Base44: обход SSO на уровне платформы

В июле 2025 Wiz Research обнаружила критическую уязвимость в Base44. Два API-эндпоинта — регистрация и OTP-верификация — не требовали аутентификации вообще. Для доступа к частным приложениям достаточно было app_id, который был публично виден в URL и манифест-файлах [13]. SSO-защита обходилась полностью. Один архитектурный дефект доступа поставил под угрозу все приложения, построенные на платформе.

Tenzai: 5 AI-платформ, 69 уязвимостей, доминируют ошибки авторизации

В декабре 2025 Tenzai протестировала Claude Code, Cursor, Windsurf, Replit и Devin на 15 приложениях. Доминирующий класс уязвимостей — не инъекции, не XSS. Бизнес-логика и авторизация: отрицательные цены при создании продуктов, возможность заказать отрицательное количество товара, admin-эндпоинты, доступные любому аутентифицированному пользователю [4].

Исследователи Tenzai резюмировали: «Человек-разработчик интуитивно понимает, как должен работать workflow. Агент лишён этого здравого смысла и зависит от явных инструкций» [14].

Silent authentication failure в Fortune 50

Apiiro описала конкретный инцидент: AI-driven pull request изменил заголовок авторизации в нескольких сервисах сразу. Один из downstream-сервисов не получил обновления — возникла тихая ошибка аутентификации (silent authentication failure) [2]. Никаких видимых сигналов, никаких исключений. Просто данные, которые не должны были быть доступны, стали доступны.

Почему это сложнее поймать, чем обычный баг

SAST не видит логических дефектов доступа

Традиционные статические анализаторы работают с паттернами: они знают, как выглядит SQL-инъекция или небезопасная десериализация. Они не знают, что «этот эндпоинт должен требовать роль admin, а не просто authenticated» — это семантическое знание о системе, а не синтаксический паттерн. Tenzai прямо констатирует: «Ваш сканер поймает SQL-инъекцию. Он пропустит "этот эндпоинт должен требовать admin, но не требует"» [4].

AI создаёт большие, многофайловые изменения

Apiiro зафиксировала, что AI-ассистенты упаковывают больше кода в меньшее число pull requests, при этом изменения затрагивают большее число компонентов кодовой базы [2]. Это делает ревью механически сложнее: рецензент теряет способность удержать в голове полный контекст изменения.

Разрыв между ощущением и реальностью

Данные Sonar (январь 2026): 96% разработчиков не доверяют AI-коду полностью — но при этом лишь 48% стабильно проверяют его перед коммитом [4]. Исследование METR (июль 2025) зафиксировало, что опытные разработчики с AI-инструментами были уверены, что стали на 20% быстрее, тогда как реально тратили на задачи на 19% больше времени [15]. Ускорение набора кода создаёт иллюзию ускорения мышления.

Veracode добавляет: 58% разработчиков доверяют AI-коду без тестирования [16]. Это означает, что дефекты доступа не просто генерируются — они попадают в продакшен с меньшим числом проверок, чем код, написанный человеком.

Итерация с AI не исправляет безопасность — она усугубляет её

Контролируемый эксперимент IEEE-ISTAS 2025 (arxiv 2506.11022) показал: после пяти раундов AI-assisted code refinement количество критических уязвимостей выросло на 37.6% [17]. Инстинкт «пофиксить через AI» не решает проблему безопасности — он её накапливает.

Специфика ошибок доступа в разных технических контекстах

API и REST-эндпоинты

Наиболее частый паттерн: AI генерирует GET-эндпоинт с авторизационной проверкой, но пропускает проверку для POST/PUT/DELETE на том же ресурсе. Авторизация применяется только к части HTTP-методов — классический OWASP A01-паттерн [8].

Облачные конфигурации и IAM

Когда AI генерирует CloudFormation или Terraform-шаблоны, он последовательно воспроизводит паттерн over-permissive IAM: при запросе «Lambda, которой нужен доступ к S3», модель генерирует s3:* для всех бакетов вместо минимально необходимых прав [18]. Apiiro нашла, что AI-разработчики вдвое чаще экспонируют Azure Service Principals и Storage Access Keys по сравнению с не-AI коллегами [2].

Row Level Security в базах данных

Базы данных с поддержкой RLS (Supabase, PostgreSQL) требуют явного определения политик для каждой таблицы. AI последовательно генерирует схемы без RLS или с некорректными политиками, открывая доступ к данным на уровне хранилища — ниже любого application-level контроля [12].

Agentic AI и MCP

Новый контекст 2025-2026 годов: AI-агенты с доступом к инструментам. OWASP LLM Top 10 2025 добавил LLM06 Excessive Agency — ситуацию, когда LLM-системе дано слишком много автономии [19]. CVE-2025-53109: MCP-сервер Anthropic позволял атакующим читать и писать произвольные файлы — ограничения доступа просто не работали [14]. Когда агент выполняет действия автономно, IAM оценивает их против идентичности агента, а не разработчика — традиционная атрибуция доступа исчезает.

Чек-лист: что проверять в AI-коде до merge

Практически всё перечисленное ниже невидимо для стандартного автоматического сканирования — это точки для мануального контроля или специализированных инструментов анализа изменений.

На уровне каждого эндпоинта

• Проверяется ли, что текущий пользователь _владеет_ ресурсом, к которому обращается (object-level authorization), а не только то, что он аутентифицирован?
• Применяется ли проверка авторизации ко _всем_ HTTP-методам (GET / POST / PUT / DELETE / PATCH)?
• Есть ли проверка авторизации на сервере, а не только на клиенте?
• Не открыты ли admin-функции любому аутентифицированному пользователю?

На уровне данных

• Включена ли RLS для всех таблиц, содержащих чувствительные данные?
• Не возвращает ли API больше полей, чем требует текущий контекст пользователя (excessive data exposure)?
• Нет ли прямых числовых ID в URL для чувствительных объектов без проверки принадлежности?

На уровне облачной конфигурации и IAM

• Применён ли принцип минимальных привилегий к cloud-ролям и политикам?
• Нет ли wildcard-политик (s3:, :*) там, где достаточно точечных прав?
• Не экспонированы ли service credentials в коде или конфигах?

На уровне архитектуры

• Есть ли централизованный middleware для проверки авторизации, а не разрозненные проверки в каждом обработчике?
• Применяется ли принцип deny-by-default (отклонять всё, что явно не разрешено)?
• Не завязана ли авторизация на UI-элементы или hidden fields без серверного контроля?

На уровне агентного кода

• Имеет ли AI-агент только минимально необходимый набор прав для своих действий?
• Верифицируются ли действия агента относительно идентичности _пользователя_, инициировавшего задачу?
• Есть ли audit log действий агента с привязкой к конкретному запросу?

Почему обычный обзор PR недостаточен

Распространённый ответ на проблему безопасности AI-кода — «просто делайте тщательный code review». Это необходимо, но недостаточно по нескольким причинам.

Во-первых, объём изменений растёт. AI-assisted разработчики генерируют в 3-4 раза больше кода — при том что их коллеги-рецензенты работают с той же скоростью [2]. Объём ревью не масштабируется линейно с объёмом кода.

Во-вторых, ошибки доступа контекстуальны. Чтобы заметить отсутствующую проверку авторизации, нужно удерживать в голове всю модель прав системы, а не только текущий файл. Это когнитивно дорого и деградирует при усталости и давлении дедлайнов.

В-третьих, сами ревьюеры работают с AI. Если разработчик пишет 95% кода с ИИ-помощью и сам же его ревьюирует, он с высокой вероятностью пропустит те же классы ошибок, которые породил ИИ — потому что у него нет независимого взгляда на логику доступа.

Именно здесь появляется запрос на специализированный слой контроля — не замену SAST или SCA, а дополнительный анализ изменения _в контексте_: что именно меняется в правах доступа, зависимостях, конфигах и каков риск конкретного PR для конкретного релиза. Инструменты вроде HighVibe решают именно эту задачу: анализ конкретного изменения до merge, с объяснением риска и предложением следующего шага команде — не длинный отчёт, а короткий ответ на вопрос «можно ли это безопасно принять прямо сейчас».

Тренды и вектор угрозы

Атаки на сам AI-агент

2025-2026 годы принесли новый класс атак — не на код, который пишет AI, а на сам инструмент генерации. Rules File Backdoor: злоумышленник встраивает инструкции в конфигурационные файлы (.cursor/rules, .clinerules), которые AI читает как контекст и следует им при генерации кода [14]. MCP configuration poisoning: компрометация MCP-сервера позволяет инструктировать агента генерировать намеренно уязвимый код.

Package hallucinations и slopsquatting

AI галлюцинирует несуществующие зависимости. Атакующие регистрируют пакеты под этими именами в PyPI и npm. Импортируя «помощную» библиотеку, разработчик получает вредоносный код в своей цепочке поставок [20]. Это не классическая ошибка доступа — но это атака на supply chain через уязвимость самого процесса AI-генерации.

Законодательное давление

Европейский акт об AI (EU AI Act), вступивший в силу в августе 2025, и рамочный документ General-Purpose AI Code of Practice устанавливают требования к безопасности AI-систем [21]. DORA (Digital Operational Resilience Act) ожидает документированных проверок безопасности даже для AI-authored кода [20]. Это означает, что организации без формального контроля AI-кода получают регуляторный риск поверх технического.

Как выстроить контроль: практический фреймворк

Ниже — три слоя защиты, которые работают в совокупности.

Слой 1: инструментальные контроли (tool controls)

• Политики промптов: явно включать требования безопасности в системные инструкции AI-ассистента — описание модели привилегий, принцип least privilege, требование server-side authorization checks.
• Запрет direct access AI-агентов к продакшен-окружениям; sandbox-изоляция для агентного кодинга.
• Контроль MCP-серверов: ревью конфигурации и ограничение прав агента до минимально необходимых.

Слой 2: gates на уровне кода (code gates)

• Специализированное сканирование изменений, ориентированное на бизнес-логику и авторизационные паттерны — не только классический SAST.
• Проверка зависимостей с alert на новые и транзитивные пакеты, в том числе на предмет package hallucinations.
• Автоматическая проверка IAM-политик и RLS-конфигураций в CI/CD.
• Блокирующий gate для критических изменений: авторизация, аутентификация, управление секретами.

Слой 3: процессные контроли (process controls)

• Threat modeling до написания кода для компонентов с логикой доступа.
• Разделение ревью: AI-код должен проверять человек, не генерировавший его.
• Security champions в командах, ответственные за знание модели привилегий системы.
• Регулярный пересмотр access control policies по мере роста кодовой базы.

Заключение: скорость без контроля — это масштабированный риск

AI действительно ускорил разработку. Синтаксические ошибки снизились. Логические баги уменьшились. Скорость набора кода выросла кратно. Но именно там, где AI хорош в поверхностной корректности, он систематически слаб в семантической безопасности — особенно в том, что касается контроля доступа.

Ошибки доступа опаснее обычных багов не потому, что их сложнее найти технически. Они опаснее потому, что:

• они архитектурны и дороги в исправлении;
• они не видны традиционному SAST;
• они не тестируются обычными юнит-тестами;
• они масштабируются вместе со скоростью генерации AI-кода;
• и они напрямую ведут к утечкам данных, обходу бизнес-логики и несанкционированному доступу.

Правило простое: если вы мандатируете AI-кодинг, необходимо мандатировать AI AppSec в параллель [2]. Иначе вы масштабируете риск с той же скоростью, что и производительность.

Источники

[1] OWASP — "A01:2021 Broken Access Control" — https://owasp.org/Top10/A01_2021-Broken_Access_Control/

[2] Apiiro — "4x Velocity, 10x Vulnerabilities: AI Coding Assistants Are Shipping More Risks" — https://apiiro.com/blog/4x-velocity-10x-vulnerabilities-ai-coding-assistants-are-shipping-more-risks/

[3] SoftwareSeni — "AI-Generated Code Security Risks: Why Vulnerabilities Increase 2.74x" — https://www.softwareseni.com/ai-generated-code-security-risks-why-vulnerabilities-increase-2-74x-and-how-to-prevent-them/

[4] Pixee — "69 Vulnerabilities in 5 AI Coding Platforms" — https://www.pixee.ai/weekly-briefings/ai-coding-platforms-vulnerabilities-scanners-miss-2026-01-21

[5] Wikipedia — "Vibe coding" — https://en.wikipedia.org/wiki/Vibe_coding

[6] BSG — "OWASP Top 10 2025: What Changed and Why It Matters" — https://bsg.tech/blog/owasp-top-10/

[7] The Register — "OWASP Top 10: Broken access control still tops app security list" — https://www.theregister.com/2025/11/11/new_owasp_top_ten_broken/

[8] IntelligenceX — "Broken Access Control (A01:2025): Complete Guide" — https://blog.intelligencex.org/broken-access-control-owasp-a01-2025-complete-guide

[9] Endor Labs — "The Most Common Security Vulnerabilities in AI-Generated Code" — https://www.endorlabs.com/learn/the-most-common-security-vulnerabilities-in-ai-generated-code

[10] Veracode — "2025 GenAI Code Security Report" — https://www.veracode.com/resources/analyst-reports/2025-genai-code-security-report/

[11] SoftwareSeni — "Security Risks in AI-Generated Code and How to Mitigate Them" — https://www.softwareseni.com/security-risks-in-ai-generated-code-and-how-to-mitigate-them/

[12] NVD — "CVE-2025-48757 Detail" — https://nvd.nist.gov/vuln/detail/CVE-2025-48757

[13] Autonoma — "Vibe Coding Failures: 7 Real Apps That Broke in Production" — https://getautonoma.com/blog/vibe-coding-failures

[14] Mothasa Substack — "Vibe Coding Has a Security Problem Nobody Wants to Talk About" — https://mothasa.substack.com/p/vibe-coding-has-a-security-problem

[15] Хабр — "Почему ИИ-код создаёт больше проблем, чем решает" — https://habr.com/ru/articles/1025170/

[16] Veracode — "AI-Generated Code Security Risks" — https://www.veracode.com/blog/ai-generated-code-security-risks/

[17] BeyondScale — "Vibe Coding Security Risks: Enterprise Guide 2026" — https://beyondscale.tech/blog/vibe-coding-security-risks-enterprise

[18] BeyondScale — "Vibe Coding Security Risks: Enterprise Guide 2026 (IAM section)" — https://beyondscale.tech/blog/vibe-coding-security-risks-enterprise

[19] BSG — "OWASP LLM Top 10 (2025): Vulnerabilities & Mitigations" — https://bsg.tech/blog/owasp-llm-top-10/

[20] Finance Herald — "How to Fix the Hidden Security Risks of Vibe Coding" — https://markets.financialcontent.com/minyanville/article/abnewswire-2025-11-11-report-how-to-fix-the-hidden-security-risks-of-vibe-coding-and-why-platforms-like-fiverr-are-becoming-the-go-to-solution

[21] Wikipedia — "General-Purpose AI Code of Practice" — https://en.wikipedia.org/wiki/General-Purpose_AI_Code_of_Practice