Ошибки авторизации в приложении: как пользователь получает лишние права

Права доступа — это не «галочка» в настройках. Это архитектурное решение, которое либо держит систему, либо её разваливает.

Введение: почему «работает» не значит «безопасно»

Когда инженер сдаёт задачу, типичный критерий приёмки один: функционал работает. Форма отправляет данные, страница открывается, API возвращает нужный ответ. Проблема в том, что авторизация — это про то, что должно _не_ работать в неправильных руках. И именно это проверяется хуже всего.

Broken Access Control (BAC) — нарушение контроля доступа — занимает первое место в OWASP Top 10 с 2021 года и остаётся на нём в редакции 2025 года [1]. Согласно данным, собранным OWASP, та или иная форма BAC присутствует в 94–100% проверенных приложений: 318 000+ инцидентов, 34 задействованных CWE — больше, чем в любой другой категории [2][6]. При этом проблема не всегда выражается в явном взломе. Чаще это тихая логическая дыра: пользователь видит чужой счёт, менеджер случайно получает права администратора, API-эндпоинт обрабатывает запросы без проверки роли вызывающей стороны.

Эта статья — о том, как именно пользователь получает лишние права, почему это происходит снова и снова, и что команды могут сделать до того, как уязвимость окажется в продакшне.

Что такое авторизация и где она ломается

Прежде чем разбирать конкретные ошибки, важно разграничить два термина, которые часто путают.

Аутентификация — это ответ на вопрос «кто ты?». Авторизация — ответ на вопрос «что тебе разрешено?». Система может корректно определить личность пользователя (аутентификация работает), но при этом выдать ему права, которые ему не положены (авторизация сломана).

OWASP формулирует суть проблемы кратко: нарушение контроля доступа происходит, когда пользователь может выполнять действия или обращаться к данным, выходящим за рамки его предполагаемых привилегий [1]. MITRE классифицирует это как CWE-284 (Improper Access Control) и CWE-269 (Improper Privilege Management) [7][8].

Уязвимость реализуется двумя основными способами:

1. Вертикальная эскалация привилегий: обычный пользователь получает доступ к функциям, предназначенным для более привилегированных ролей — администратора, суперпользователя, оператора.
2. Горизонтальная эскалация привилегий: пользователь получает доступ к данным или функциям другого пользователя того же уровня — например, читает чужой профиль или изменяет чужой заказ [9].

Механизмы: как именно это происходит

IDOR — самая распространённая форма горизонтальной эскалации

Insecure Direct Object Reference (IDOR, небезопасная прямая ссылка на объект) — это когда приложение использует идентификатор, переданный клиентом, для прямого обращения к объекту без проверки, имеет ли этот клиент право на данный объект [10].

Пример: запрос GET /api/orders/12345 возвращает заказ с указанным ID. Если сервер не проверяет, принадлежит ли этот заказ текущему авторизованному пользователю, любой залогиненный пользователь может получить чужой заказ, просто перебрав числа.

Идентификаторы встречаются повсюду: в пути URL (/users/123), в параметрах запроса (?account=987), в теле JSON, в заголовках HTTP. IDOR относится к OWASP API1:2023 — Broken Object Level Authorization (BOLA) и остаётся первым пунктом в списке API-угроз [10][11].

Реальные примеры: в 2023 году исследователь HackerOne обнаружил в TikTok возможность менять настройки приватности «Воспоминаний» других пользователей, манипулируя параметром aweme_id. CVE-2024-28320 в Hospital Management System с CVSS 7.6 позволял читать и изменять данные пациентов. CVE-2025-13526 в плагине WordPress OneClick Chat to Order открывал доступ к данным покупателей через манипуляцию параметром URL [11].

JWT-манипуляции и атаки на токены

JSON Web Token (JWT) — широко распространённый механизм передачи данных авторизации между клиентом и сервером. Токен состоит из трёх частей: заголовка, полезной нагрузки (payload) и подписи. Ключевой момент: payload кодируется Base64, но не шифруется — содержимое можно прочитать без ключа [12].

Ошибки при работе с JWT открывают несколько векторов атаки.

Манипуляция claims. Если сервер доверяет содержимому payload без независимой проверки, изменение значения role: "user" на role: "admin" или isAdmin: false на isAdmin: true даёт атакующему административные права [13]. Это классический сценарий вертикальной эскалации.

Алгоритм none. Некоторые реализации принимают JWT с алгоритмом "alg": "none", то есть без подписи вообще. Атакующий удаляет подпись, меняет claims и отправляет невалидный токен, который сервер принимает [14][15].

Путаница verify() и decode(). В популярной библиотеке jsonwebtoken для Node.js есть два метода: verify() проверяет подпись, decode() — нет. Разработчик, случайно использующий decode() вместо verify(), эффективно отключает всю проверку подлинности токена [14].

Подбор слабого секрета. Если HS256-токен подписан слабым секретом, атакующий может подобрать его брутфорсом, а затем создавать произвольные токены с любыми claims [15].

Согласно результатам реальных пентестов 2025 года, манипуляция JWT для получения привилегий остаётся одной из наиболее часто воспроизводимых уязвимостей в российских и международных приложениях [16].

Пропущенные проверки на API-эндпоинтах

Это, пожалуй, самая «тихая» из ошибок. Разработчик реализует проверку роли на одном эндпоинте, но забывает о паре смежных. Особенно часто это происходит при:

• добавлении нового эндпоинта в спешке — проверка авторизации не копируется из аналогичных методов;
• рефакторинге — логика авторизации вынесена в middleware, но новый маршрут не подключён к нему;
• различиях между HTTP-методами — GET /admin/users проверяет роль, а POST /admin/users — нет;
• несоответствии UI и API — фронтенд скрывает кнопку для обычных пользователей, но сам эндпоинт доступен напрямую [1][6].

Классический паттерн описан в OWASP: «access control is only effective when implemented in trusted server-side code or serverless APIs, where the attacker cannot modify the access control check or metadata» [1]. Любая логика, реализованная только на клиентской стороне, не является контролем доступа — это лишь пользовательский интерфейс.

RBAC-ошибки и «взрыв ролей»

Role-Based Access Control (RBAC) — стандарт де-факто для управления правами в приложениях. Роли привязываются к разрешениям, пользователи получают роли. Пока модель небольшая, всё работает предсказуемо.

Проблемы начинаются при масштабировании. Явление, называемое «role explosion» (взрыв ролей), возникает когда каждому пользователю нужен уникальный набор доступов, и чтобы его обеспечить, создаётся всё больше специфических ролей. В результате:

• одному пользователю назначается несколько ролей, часть из которых избыточна;
• проверить реальные права становится трудоёмко;
• при смене должности или уходе сотрудника устаревшие роли не отзываются [17].

Избыточные права по умолчанию — отдельная системная проблема. Новый пользователь регистрируется и получает более широкий набор разрешений, чем ему реально нужен. Это нарушение принципа наименьших привилегий (principle of least privilege, PoLP), который NIST и OWASP называют фундаментальным требованием к любой системе контроля доступа [5][18].

Force browsing и прямой перебор URL

Force browsing — это техника прямого обращения к URL или API-эндпоинтам, которые не отображаются в интерфейсе, но остаются доступными на сервере. Примеры:

• /admin/panel доступен без авторизации, потому что разработчик убрал ссылку из меню, но забыл добавить проверку прав на сам роут;
• /api/v1/reports/export работает без проверки роли, хотя в UI кнопка видна только менеджерам [1][6].

Это следствие ошибочного убеждения «security through obscurity» — безопасность через неочевидность. Скрытый URL не является защищённым URL.

AI-код и новый масштаб проблемы

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

Данные исследований показательны. Veracode в отчёте 2025 года установил, что 45% AI-генерируемого кода содержит уязвимости безопасности [3]. По данным SQ Magazine, к середине 2025 года AI-генерируемый код производил более 10 000 новых security-находок в месяц — рост в 10 раз по сравнению с концом 2024 года [3]. Отчёт Cycode 2026 года фиксирует: 92% организаций активно используют AI-ассистентов в разработке, при этом AI-генерируемый код стал «слепым пятном номер один» для команд безопасности [19].

Специфика AI-кода и авторизации: языковые модели хорошо воспроизводят часто встречающиеся паттерны, но плохо учитывают контекст конкретного приложения. Сгенерированный эндпоинт может не унаследовать middleware авторизации, уже применённый к остальным роутам. Код «работает» — данные возвращаются, функционал реализован. Но проверка прав пропущена [20][52].

Человеческий фактор усиливает риск: 58% разработчиков доверяют AI-коду без дополнительного тестирования [3]. Ревью PR «дочитывают не до конца» — это стандартная производственная реальность, особенно в условиях ускоренных релизных циклов.

Реальные кейсы и последствия

GitHub (2022)

Уязвимость в GitHub позволяла пользователям получать повышенный уровень доступа к репозиториям без авторизации, манипулируя параметрами или обращаясь к незащищённым эндпоинтам. Обычные пользователи получали функции, ограниченные для администраторов репозитория [9].

Mealie v2.2.0 (CVE задокументирована OWASP)

Компонент /households/permissions в приложении Mealie позволял менеджерам группы редактировать собственные разрешения через PUT-запрос с явным указанием прав: canInvite, canManageHousehold, canManage и canOrganize — все true. Пользователь сам себе назначал права, которых у него не было [1].

First American EaglePro

Любой пользователь мог получить доступ к документам об эскроу и правах собственности других пользователей, просто изменив параметр URL в приложении EaglePro — без дополнительной аутентификации и авторизации [27].

Российские приложения: JWT-уязвимости

По данным реальных пентестов 2025 года, в ряде российских приложений на базе Bitrix был выявлен слабый секрет JWT. Атакующий перехватывал токен, подбирал секрет через Burp Suite с расширением JWT Editor, изменял user_id и получал доступ к административной панели [16].

Масштаб ущерба

IBM Cost of a Data Breach Report 2024 фиксирует: компрометация учётных данных и злоупотребление привилегиями стоят в среднем $4,5 млн на инцидент и составляют около 20% всех утечек. Средний срок обнаружения взлома — 194 дня [4][5]. За это время злоумышленник может систематически извлекать данные, изучать инфраструктуру и готовить следующий шаг.

Принципы защиты: от теории к операционным решениям

Принцип наименьших привилегий (PoLP) и deny-by-default

Каждый пользователь, сервис и компонент должны иметь только минимальный набор прав, необходимых для выполнения своей задачи — и ничего сверх. По умолчанию доступ запрещён: любое исключение требует явного разрешения [1][5].

Операционный вывод: при проектировании нового функционала начинайте с вопроса «кто должен это видеть и делать?», а не с вопроса «кому это нужно запретить». Модель deny-by-default меняет направление рассуждений.

Авторизация только на сервере

Любая логика доступа, реализованная на клиентской стороне, не является защитой. Скрытые кнопки, условный рендеринг, клиентские фильтры — это UX, не security. Все авторизационные проверки должны быть реализованы на сервере и применяться к каждому запросу независимо от того, откуда он пришёл [1][18].

Централизованная реализация

Реализуйте авторизационный механизм один раз и переиспользуйте его по всему приложению — через middleware, policy engine или единый авторизационный сервис. Разрозненные проверки, разбросанные по эндпоинтам, неизбежно приводят к пропускам [18][44].

Авторизация должна покрывать:

1. все HTTP-методы (GET/POST/PUT/DELETE/PATCH) для каждого защищённого ресурса;
2. API-эндпоинты независимо от UI — даже если кнопки нет в интерфейсе;
3. функциональный уровень (Broken Function Level Authorization, BFLA) — кто может вызвать данную операцию;
4. объектный уровень (BOLA/IDOR) — имеет ли конкретный пользователь право на конкретный объект.

Безопасная работа с JWT

• Проверяйте подпись на каждый запрос — используйте verify(), а не decode() [14].
• Жёстко задавайте допустимый алгоритм — отклоняйте токены с "alg": "none" или неожиданным алгоритмом [22].
• Не доверяйте claims без независимой верификации на сервере — роль пользователя должна проверяться в базе данных, а не браться из токена [13].
• Используйте короткий TTL для access-токенов; для долгоживущих сессий применяйте refresh-токены по стандарту OAuth [17].
• Используйте криптографически сильные секреты — не строки вроде secret, password или myapp [15].

Регулярный аудит прав доступа

• Проводите периодический аудит назначенных ролей — особенно для сотрудников, сменивших должность, и уволенных.
• Автоматизируйте отзыв прав при деактивации учётной записи.
• Мониторьте аномальные паттерны доступа: последовательный перебор ID, обращения к эндпоинтам вне обычного workflow, множественные запросы к объектам разных пользователей [10][46].

Принцип записи права собственности

Для объектов, принадлежащих конкретному пользователю (записи, файлы, транзакции), проверяйте не только «имеет ли пользователь доступ к ресурсу этого типа», но и «принадлежит ли этот конкретный объект текущему пользователю» [1]. Это устраняет IDOR на уровне архитектуры.

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

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

Перед merge:

• [ ] Новый эндпоинт подключён к centralized авторизационному middleware
• [ ] Все HTTP-методы для ресурса проверяют права (не только GET, но и POST/PUT/DELETE)
• [ ] Нет логики ролей на клиентской стороне без серверного дублирования
• [ ] JWT claims верифицируются, а не просто декодируются
• [ ] Нет хардкода ролей (if user.id == 1: grant_admin) вместо политики

Перед релизом:

• [ ] Новые API-эндпоинты покрыты тестами авторизации (как минимум: аноним, пользователь без нужной роли, пользователь с нужной ролью)
• [ ] Проверены сценарии горизонтальной эскалации: пользователь A не может получить объекты пользователя B
• [ ] Аудит новых зависимостей на наличие уязвимостей авторизации (CVE-проверка)
• [ ] Конфигурация CORS не разрешает запросы с произвольных источников к чувствительным эндпоинтам

Для AI-генерируемого кода:

• [ ] Авторизационный контекст явно передаётся в промпт при генерации эндпоинтов
• [ ] Сгенерированный код проверяется на наличие авторизационных проверок до коммита
• [ ] Новые роуты явно сопоставляются с существующей матрицей прав

Ошибки и антипаттерны: как это ломается на практике

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

Антипаттерн 1: авторизация через UI-сокрытие. Разработчик скрывает кнопку «Удалить» для обычного пользователя, но сам DELETE-эндпоинт не защищён. Злоумышленник отправляет запрос напрямую через curl или Burp Suite [6][62].

Антипаттерн 2: проверка роли по клиентскому параметру. Запрос содержит ?role=admin, и сервер использует это значение для принятия решения об авторизации. Атакующий просто добавляет параметр в запрос [2].

Антипаттерн 3: JWT без re-verification. Роль пользователя берётся из токена без проверки в базе данных. Если права пользователя были понижены, он продолжает пользоваться старым токеном с повышенными правами до истечения TTL [14].

Антипаттерн 4: принцип «это внутренний инструмент, его никто не найдёт». Административные панели и internal tools без авторизации — отдельная категория рисков. По статистике HackerOne, именно в них security-команды находят критические уязвимости при первых пентестах [56].

Антипаттерн 5: «мы используем GUID, значит IDOR нам не грозит». UUID сложнее перебрать, но не делает IDOR невозможным — достаточно утечки одного идентификатора из другого источника (лог, аналитика, email с ссылкой) [10][11].

AI-кодинг и авторизация: новый контрольный слой

Если ваша команда активно использует AI-ассистентов — а по данным Cycode, это 92% организаций — то контроль авторизации становится критичным именно на уровне PR и релизного gate [19].

Сгенерированный код хорош в реализации функционала. Он значительно хуже в учёте контекста безопасности: какой middleware применён к этому router, какая политика действует для этого типа объектов, нужна ли здесь проверка ownership. Это не упрёк языковым моделям — это их архитектурная особенность. Они не знают вашу систему, если вы не вложили её в контекст.

Следствие: PR с новыми эндпоинтами или изменениями в логике ролей требует явной авторизационной проверки как части ревью. Не «посмотреть, работает ли», а «убедиться, что доступ правильно ограничен». Это разные вопросы, и автоматические тесты на функционал не отвечают на второй.

Здесь уместен дополнительный слой контроля. Инструменты вроде HighVibe анализируют конкретное изменение — новый эндпоинт, изменённый middleware, обновлённую конфигурацию — в контексте релиза и помогают команде заметить риск до merge. Не ещё один длинный security-отчёт, а короткий ответ на вопрос «что действительно блокирует выпуск». Это не замена SAST/SCA или пентеста — это дополнительная точка контроля там, где скорость AI-разработки создаёт слепые зоны.

Тренды и что будет дальше

Несколько тенденций, которые влияют на ландшафт ошибок авторизации в 2025–2026 годах.

Рост API-поверхности. Микросервисная архитектура и SaaS-интеграции увеличивают количество API-эндпоинтов, каждый из которых нуждается в собственных авторизационных проверках. По данным OWASP, именно API-приложения показывают наиболее высокую концентрацию BOLA-уязвимостей [10].

Смещение к ABAC и ReBAC. Классический RBAC испытывает ограничения при сложных иерархиях и контекстно-зависимых решениях о доступе. NIST признаёт Attribute-Based Access Control (ABAC) и Relationship-Based Access Control (ReBAC) как более гибкие модели для современных систем [17][18]. Но эта гибкость увеличивает поверхность для ошибок конфигурации.

AI и non-deterministic поведение. Агентный AI-код открывает новую категорию авторизационных рисков: агент действует с правами разработчика или сервисного аккаунта, и эти права часто избыточны. Инцидент с Amazon Kiro в конце 2025 года — показательный пример того, как «правильно работающий» инструмент с избыточными правами может привести к серьёзным последствиям [52].

Zero Trust как архитектурный сдвиг. «Доверяй, но проверяй» уступает место «никогда не доверяй, всегда проверяй». Это означает авторизацию на каждом уровне стека — не только на внешнем периметре, но и во внутренних сервисах, ci/cd пайплайнах, инфраструктурных компонентах.

Заключение

Ошибки авторизации — это не экзотика и не редкое стечение обстоятельств. Это системная проблема, присутствующая в большинстве приложений и занимающая первую строчку OWASP Top 10 не случайно. Её не решить одним инструментом или одной проверкой — это вопрос архитектуры, процессов и культуры в команде.

Что делать дальше:

1. Провести аудит существующих API-эндпоинтов на наличие авторизационных проверок — особенно тех, что создавались в спешке или через AI-ассистентов.
2. Внедрить централизованный авторизационный middleware и убедиться, что все роуты его используют.
3. Добавить авторизационные тесты как обязательный элемент приёмки PR для новых эндпоинтов.
4. Проверить конфигурацию JWT — алгоритм, TTL, метод верификации.
5. Ввести процедуру регулярного аудита прав: кто что имеет, и нужно ли это ему сейчас.

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

Источники

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

[2] IntelligenceX Cybersecurity Blog — "Broken Access Control (A01:2025): The #1 OWASP TOP 10 Vulnerability — Complete Guide" — https://blog.intelligencex.org/broken-access-control-owasp-a01-2025-complete-guide

[3] SQ Magazine — "AI Coding Security Vulnerability Statistics 2026: Alarming Data" — https://sqmagazine.co.uk/ai-coding-security-vulnerability-statistics/

[4] AstrillVPN Blog — "Understanding Privilege Escalation: Attacks, Types, and Techniques" — https://www.astrill.com/blog/privilege-escalation/

[5] OWASP Foundation — "IDOR: Insecure Direct Object Reference" — https://owasp.org/www-community/attacks/insecure_direct_object_reference

[6] Authgear — "What is Broken Access Control Vulnerability and How to Prevent It" — https://www.authgear.com/post/what-is-broken-access-control-vulnerability-and-how-to-prevent-it/

[7] CVEDetails — "CWE-284: Improper Access Control" — https://www.cvedetails.com/cwe-details/284/Improper-Access-Control.html

[8] CVEDetails — "CWE-269: Improper Privilege Management" — https://www.cvedetails.com/cwe-details/269/Improper-Privilege-Management.html

[9] IntelligenceX Cybersecurity Blog — "Broken Access Control: GitHub 2022 real-world example" — https://blog.intelligencex.org/broken-access-control-owasp-a01-2025-complete-guide

[10] OWASP Foundation — "Testing for Insecure Direct Object References" — https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/04-Testing_for_Insecure_Direct_Object_References

[11] SentinelOne — "Insecure Direct Object Reference (IDOR)" — https://www.sentinelone.com/cybersecurity-101/cybersecurity/insecure-direct-object-reference/

[12] Acunetix — "JSON Web Token Attacks And Vulnerabilities" — https://www.acunetix.com/blog/articles/json-web-token-jwt-attacks-vulnerabilities/

[13] Traceable AI — "JWTs Under the Microscope: How Attackers Exploit Authentication and Authorization Weaknesses" — https://www.traceable.ai/blog-post/jwts-under-the-microscope-how-attackers-exploit-authentication-and-authorization-weaknesses

[14] PortSwigger Web Security Academy — "JWT attacks" — https://portswigger.net/web-security/jwt

[15] HackTricks — "JWT Vulnerabilities (Json Web Tokens)" — https://book.hacktricks.xyz/pentesting-web/hacking-jwt-json-web-tokens

[16] ABP2B — "15 критичных уязвимостей 2025 года по итогам реальных пентестов" — https://abp2b.com/tpost/rcrs5vpak1-15-kritichnih-uyazvimostei-2025-goda-po

[17] Axiomatics — "Four Role-Based Access Control (RBAC) Limitations and How to Fix Them" — https://axiomatics.com/news/press-releases/four-role-based-access-control-rbac-limitations-and-how-to-fix-them

[18] Security Journey — "Broken Access Control: OWASP Top 10 Guide 2026" — https://www.securityjourney.com/post/owasp-top-10-broken-access-control-explained

[19] Cycode — "Application Security Vulnerabilities to Watch out for in 2026" — https://cycode.com/blog/application-security-vulnerabilities/

[20] Vitalii Petrenko / Medium — "40% of AI-Generated Code Has Security Flaws. Your Code Review Won't Catch Them." — https://vitalii4reva.medium.com/40-of-ai-generated-code-has-security-flaws-your-code-review-wont-catch-them-0a02a13848fe