The article addresses REST API vulnerabilities and protection methods. Based on the OWASP API Security Top 10 (2023), typical attack vectors are systematized: authorization flaws (BOLA, BFLA, BOPLA), authentication attacks, server-side request forgery (SSRF), and unrestricted resource consumption. The protection measures discussed include the use of OAuth 2.0 and OpenID Connect, the correct application of JWT, OpenAPI schema validation, request rate limiting, and the use of API gateways and WAF.

Keywords: information security, REST API, OWASP, authentication, authorization, JWT, OAuth 2.0, SSRF.

Введение

Современные распределённые системы строятся на взаимодействии сервисов через программные интерфейсы. Архитектурный стиль REST стал де-факто стандартом таких интерфейсов благодаря простоте и соответствию семантике HTTP [1]. По данным отчёта Salt Security, в 2024 году более 80 % корпоративного трафика приходится на вызовы API, при этом число инцидентов, связанных с эксплуатацией уязвимостей API, продолжает расти [2]. Атаки на API отличаются от классических атак на веб-приложения: API предоставляет прямой доступ к бизнес-логике, что расширяет поверхность атаки. Цель настоящей работы — проанализировать основные классы уязвимостей REST-сервисов на основе перечня OWASP API Security Top 10 (2023) [3] и систематизировать методы защиты.

Классификация атак на REST-сервисы

Нарушение авторизации объектного уровня (BOLA) занимает первое место перечня. Причина — доверие к идентификаторам, переданным клиентом: запрос вида GET /api/v1/users/123/documents возвращает данные без проверки того, что текущий пользователь имеет право обращаться к этому ресурсу. Близкая уязвимость — нарушение авторизации функционального уровня (BFLA), при которой клиент с обычными правами получает доступ к административным маршрутам. Уязвимость BOPLA проявляется в раскрытии лишних свойств и в массовом присваивании, когда сервер принимает поля запроса, не предусмотренные публичным контрактом (например, is_admin: true).

Нарушение аутентификации возникает при некорректной проверке подлинности: предсказуемые токены, отсутствие защиты от перебора, использование устаревших алгоритмов хеширования, некорректное применение JWT (алгоритм «none», неограниченный срок жизни токена). Способы предотвращения подобных атак описаны в RFC 8725 [4].

Неограниченное потребление ресурсов и SSRF. Сервисы без ограничений на частоту запросов и размер данных подвержены атакам отказа в обслуживании, в облачных средах с тарификацией по объёму вычислений — «финансовому отказу в обслуживании» [2]. Подделка запросов на стороне сервера (SSRF) эксплуатирует функциональность сервиса, обращающегося к внешним ресурсам: злоумышленник подменяет URL на адрес внутренней инфраструктуры (сервис метаданных облачного провайдера, административные интерфейсы), что в микросервисной архитектуре приводит к обходу сетевого периметра.

Методы защиты REST-сервисов

Эффективная защита строится по принципу многоуровневой обороны (defense in depth). На транспортном уровне применяется протокол TLS не ниже версии 1.2 с переходом на TLS 1.3 [5], а в инфраструктурах «сервис-сервис» — взаимная аутентификация mTLS. Базовым протоколом аутентификации является OAuth 2.0 [6], дополненный OpenID Connect: для браузерных клиентов применяется Authorization Code Flow с PKCE, для межсервисного взаимодействия — Client Credentials. Токены выдаются в формате JWT (RFC 7519 [7]) с явным указанием алгоритмов подписи, ограничением срока жизни access-токена и ротацией refresh-токенов [4].

Решение проблемы BOLA требует проверки прав на уровне каждого объекта: сервис должен сверять идентификатор ресурса с субъектом токена либо со списком объектов, к которым субъект имеет явное право доступа. Для сложных моделей применяются механизмы RBAC и ABAC, а также внешние системы оценки политик (Open Policy Agent), позволяющие вынести логику авторизации в декларативные правила [8]. Параметры запроса проходят валидацию по схеме OpenAPI; для защиты от массового присваивания используются явные DTO. На каждом эндпоинте устанавливаются лимиты на размер тела, глубину вложенности JSON и время выполнения, а на уровне шлюза API — ограничение частоты запросов.

Защита от SSRF реализуется белым списком разрешённых внешних адресов, проверкой итогового IP-адреса после разрешения DNS-имени, запретом доступа к специальным диапазонам (10.0.0.0/8, 169.254.0.0/16) из исходящих запросов сервиса. Шлюз API централизует функции аутентификации, ограничения частоты и логирования, а межсетевые экраны уровня приложений (WAF) обнаруживают атаки по сигнатурам и поведенческим признакам. WAF не заменяет защитные меры на уровне приложения, а является дополнительным рубежом обороны.

Заключение

1. Современные атаки на REST-сервисы систематизируются в рамках OWASP API Security Top 10 (2023). Наибольшую распространённость имеют уязвимости уровня бизнес-логики (BOLA, BFLA, BOPLA), не выявляемые средствами автоматического сканирования.
2. Защита REST-сервисов требует многоуровневой обороны, охватывающей транспортный уровень (TLS 1.3, mTLS), аутентификацию и авторизацию (OAuth 2.0, OpenID Connect, JWT), обработку запросов (валидация по OpenAPI, DTO, ограничение ресурсов) и инфраструктуру (API-шлюзы, WAF). Организационная составляющая (актуальная документация OpenAPI, инвентаризация эндпоинтов, управление секретами) не менее значима, чем техническая.

Литература:

1. Fielding R. T. Architectural Styles and the Design of Network-based Software Architectures: Doctoral dissertation. — Irvine: University of California, 2000. — 180 p.
2. State of API Security Report [Электронный ресурс] // Salt Security. — 2024. — URL: https://content.salt.security/state-of-api-report.html (дата обращения: 15.04.2026).
3. OWASP API Security Top 10–2023 [Электронный ресурс] // OWASP. — URL: https://owasp.org/API-Security/editions/2023/en/0x11-t10/ (дата обращения: 15.04.2026).
4. Sheffer Y., Hardt D., Jones M. JSON Web Token Best Current Practices: RFC 8725 [Электронный ресурс] // IETF. — 2020. — URL: https://datatracker.ietf.org/doc/html/rfc8725 (дата обращения: 15.04.2026).
5. Rescorla E. The Transport Layer Security (TLS) Protocol Version 1.3: RFC 8446 [Электронный ресурс] // IETF. — 2018. — URL: https://datatracker.ietf.org/doc/html/rfc8446 (дата обращения: 15.04.2026).
6. Hardt D. The OAuth 2.0 Authorization Framework: RFC 6749 [Электронный ресурс] // IETF. — 2012. — URL: https://datatracker.ietf.org/doc/html/rfc6749 (дата обращения: 15.04.2026).
7. Jones M., Bradley J., Sakimura N. JSON Web Token (JWT): RFC 7519 [Электронный ресурс] // IETF. — 2015. — URL: https://datatracker.ietf.org/doc/html/rfc7519 (дата обращения: 15.04.2026).
8. Madden N. API Security in Action. — Shelter Island: Manning Publications, 2020. — 576 p.