OWASP API Security Top 10: эволюция ключевых рисков безопасности API

Почему OWASP API Security Top 10 — это стандарт индустрии

API (Application Programming Interface) стали основой цифровых сервисов. Они обеспечивают сквозное взаимодействие и обмен данными между различными сервисами, платформами и приложениями — от мобильных приложений до облачных решений. Однако широкое использование API сделало их одной из основных целей кибератак, подвергая компании рискам утечки данных, несанкционированного доступа и недоступности ключевых систем.

По прогнозам Statista, в ближайшие годы количество вызовов API увеличится в пять раз. При этом, по данным на 2024 год, 7 из 10 утечек данных происходят именно через API. В этих условиях понимание ключевых рисков безопасности API становится критически важным для любой организации.

OWASP API Security Top 10 — это отдельный рейтинг рисков для программных интерфейсов, который OWASP поддерживает параллельно с классическим OWASP Top 10 для веб-приложений. Первая версия рейтинга вышла в 2019 году, а в 2023 году OWASP выпустила существенно обновлённую версию. Этот документ стал универсальным стандартом для выявления и предотвращения основных уязвимостей API.

В этой статье мы разберём все десять рисков OWASP API Security Top 10 (версия 2023 года), сравним их с версией 2019 года и дадим практические рекомендации по защите ваших API.

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

В 2023 году в список были добавлены три новые категории:

1. Unrestricted Access to Sensitive Business Flows — неограниченный доступ к критическим бизнес-потокам

2. Server-Side Request Forgery (SSRF) — подделка запросов на стороне сервера

3. Unsafe Consumption of APIs — небезопасное потребление API

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

Переработаны следующие категории:

- Broken User Authentication → Broken Authentication (охватывает более широкий спектр проблем)

- Excessive Data Exposure и Mass Assignment объединены в Broken Object Property Level Authorization

- Lack of Resources & Rate Limiting → Unrestricted Resource Consumption

Неизменными остались три категории: Broken Object Level Authorization (BOLA), Broken Function Level Authorization (BFLA) и Security Misconfiguration.

Вот актуальный перечень десяти наиболее критичных рисков безопасности API по версии OWASP 2023 года:

Рассмотрим каждый риск подробно.

BOLA остаётся самой распространённой и опасной угрозой для API. Эта уязвимость возникает, когда API-эндпоинты не проверяют, имеет ли пользователь право доступа к конкретному объекту.

Как это работает: API обычно предоставляют конечные точки, которые обрабатывают идентификаторы объектов. Если проверки авторизации на уровне объектов отсутствуют, злоумышленник может подменить ID объекта в запросе и получить доступ к данным других пользователей.

Пример сценария атаки: Торговая онлайн-платформа предоставляет API для получения данных о доходах магазинов по адресу `/shops/{shopName}/revenue_data.json`. Злоумышленник, проанализировав запросы, может подставить имя другого магазина и получить его конфиденциальные данные.

Как защититься:

- Внедряйте проверки авторизации на уровне объектов в каждой функции, которая получает доступ к данным на основе пользовательского ввода

- Используйте случайные и непредсказуемые идентификаторы объектов

- Применяйте принцип минимальных привилегий

- Регулярно проводите аудит доступа к объектам

Реальный инцидент: В известном случае с Uber злоумышленники отправляли API-запросы с номерами телефонов пользователей, получая несанкционированный доступ к токенам и манипулируя системами.

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

Основные проблемы:

- Генерация ненадёжных паролей

- Отсутствие проверки подлинности токенов

- Возможность смены данных без подтверждения паролем

- Приём неподписанных JWT-токенов

- Отсутствие блокировки учётных записей при атаках грубой силы

- Использование ненадёжных ключей шифрования

Как защититься:

- Используйте стандарты OAuth 2.0 или OpenID Connect

- Внедряйте многофакторную аутентификацию (MFA) для всех учётных записей

- Защищайте токены сессий с помощью безопасного хранения и правил истечения срока

- Мониторьте неудачные попытки входа для предотвращения брутфорс-атак

- Проводите тщательный анализ всех механизмов проверки подлинности

Это новая категория, объединившая Excessive Data Exposure и Mass Assignment из версии 2019 года. Уязвимость возникает, когда API не обеспечивает авторизацию на уровне свойств (полей) объекта.

Как это работает: API (особенно REST API) часто возвращают все свойства объекта. Конечная точка считается уязвимой, если она:

- Предоставляет доступ ко всем свойствам объекта, включая конфиденциальные данные

- Позволяет пользователю изменять, добавлять или удалять значения свойств, которые не должны быть доступны

Пример: В финансовом SaaS-приложении пользователь может обновлять информацию своего аккаунта, но если API не проверяет права на изменение всех свойств, злоумышленник может изменить баланс счёта или историю транзакций.

Как защититься:

- Внедряйте строгие проверки доступа на уровне свойств объекта

- Используйте схемы данных (DTO) для контроля того, какие поля возвращаются и принимаются

- Не возвращайте конфиденциальные поля, если они не требуются клиенту

- Применяйте валидацию на основе ролей пользователя

Неограниченное потребление ресурсов может серьёзно повлиять на стабильность и производительность API. Это происходит, когда API использует чрезмерные системные ресурсы, что может привести к замедлению работы, отказам системы и увеличению операционных расходов.

Основные риски:

- DoS-атаки (отказ в обслуживании)

- Финансовые потери из-за неограниченного потребления платных ресурсов

- Снижение качества обслуживания для легитимных пользователей

Как защититься:

- Внедряйте Rate Limiting — ограничение количества запросов от одного клиента

- Устанавливайте таймауты и лимиты на размер полезной нагрузки

- Ограничивайте количество элементов в ответах

- Используйте механизмы circuit breaking для предотвращения каскадных отказов

Эта уязвимость осталась неизменной с 2019 года. Она возникает, когда API позволяет пользователю вызывать функции или эндпоинты, к которым у него нет прав доступа.

Как это работает: Злоумышленник может обнаружить административные эндпоинты и вызвать их, даже не имея соответствующих прав. Например, обычный пользователь может отправить запрос на `/api/admin/users` и получить список всех пользователей системы.

Как защититься:

- Внедряйте проверки авторизации на уровне функций для каждого эндпоинта

- Используйте ролевую модель доступа (RBAC)

- Применяйте принцип минимальных привилегий

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

Это новая категория в списке 2023 года. Она связана с недостаточной проработкой или ошибками в логике критических технологических цепочек бизнес-процессов, что позволяет злоумышленникам выполнять мошеннические операции.

Примеры сценариев:

- Автоматизированный выкуп товаров с использованием ботов

- Мошеннические транзакции в финансовых системах

- Массовое создание учётных записей

- Скрапинг данных в больших объёмах

Как защититься:

- Определите критические потоки данных и выберите соответствующие меры защиты

- Внедряйте поведенческий анализ для выявления аномальных паттернов

- Используйте Rate Limiting для критических бизнес-операций

- Применяйте капчу и другие механизмы защиты от ботов

- Мониторьте аномальные всплески активности

SSRF была добавлена в список актуальных угроз в 2023 году. Хотя SSRF не является новой уязвимостью, в настоящее время она стала более распространённой именно в приложениях на основе API.

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

Причины роста:

- Популярность веб-хуков упростила эксплуатацию SSRF-уязвимостей

- REST API для управления облачными сервисами, Kubernetes и Docker также упрощают эксплуатацию

Как защититься:

- Валидируйте и санитизируйте все URL, полученные от пользователя

- Используйте белые списки разрешённых доменов и IP-адресов

- Ограничьте доступ сервера к внутренним ресурсам

- Настройте сетевые политики для предотвращения доступа к внутренним сервисам

Эта категория была понижена в рейтинге по сравнению с 2019 годом, но остается серьезной проблемой. Ошибки конфигурации безопасности могут возникнуть на любом уровне — от серверов и сетей до самих API.

Типичные проблемы:

- Неправильные настройки CORS

- Включенные отладочные режимы в production

- Использование стандартных учетных данных

- Отсутствие HTTPS/TLS

- Неправильные настройки заголовков безопасности

Как защититься:

- Автоматизируйте процесс настройки безопасности (Infrastructure as Code)

- Регулярно проводите аудит конфигураций

- Используйте сканеры уязвимостей для выявления ошибок конфигурации

- Следуйте принципу безопасной конфигурации по умолчанию

Некорректное управление инвентаризацией API (ранее — Improper Assets Management) остается критической проблемой. Многие организации не имеют полного представления о том, сколько API-эндпоинтов существует в их инфраструктуре.

Основные проблемы:

- Shadow API — теневые API, созданные разработчиками без ведома security-команды

- Zombie API — устаревшие API, которые должны быть выведены из эксплуатации

- Orphaned API — API без четкого владельца

Эти скрытые API часто не имеют надлежащих средств контроля безопасности и не отслеживаются на предмет подозрительной активности.

Как защититься:

- Внедряйте автоматическое обнаружение всех API-эндпоинтов

- Введите актуальный реестр всех API с указанием владельца

- Регулярно проводите аудит на предмет теневых и устаревших API

- Используйте API-шлюзы для централизованного управления

Это новая категория в списке 2023 года. Она подчёркивает растущий риск, связанный с небезопасным потреблением API, особенно сторонних и внешних сервисов.

Основные риски:

- Использование API с известными уязвимостями

- Отсутствие проверки безопасности внешних API

- Небезопасная обработка данных, полученных от сторонних сервисов

- Атаки на цепочку поставок через скомпрометированные API

Как защититься:

- Проводите оценку безопасности всех сторонних API перед интеграцией

- Требуйте от поставщиков услуг соответствия стандартам безопасности

- Внедряйте политику минимально необходимого доступа для внешних сервисов

- Регулярно обновляйте зависимости и проверяйте их на наличие уязвимостей

1. Начните с аудита существующих API

Проведите полную инвентаризацию всех API-эндпоинтов. Выявите теневые, устаревшие и осиротевшие API. Без полной видимости невозможно выстроить эффективную защиту.

2. Внедряйте безопасность на всех этапах разработки (Shift-Left)

OWASP предоставляет не только Top 10, но и целую экосистему проектов: стандарты ASVS, методики тестирования WSTG, модели зрелости SAMM, инструменты автоматизированного анализа OWASP ZAP. Используйте их для встраивания безопасности в процесс разработки.

3. Связывайте OWASP с регуляторными требованиями

Для российских организаций OWASP API Security Top 10 становится практическим чеклистом при реализации мер ФСТЭК (приказы №117, №21, №239) на прикладном уровне. Каждая из 10 категорий маппится на меры ФСТЭК групп ИАФ, УПД, ЗИС, АНЗ, ИНВ.

4. Используйте автоматизированные инструменты

Внедряйте инструменты для автоматического обнаружения уязвимостей API (Burp Suite, OWASP ZAP). Используйте решения, которые интегрируются в CI/CD-пайплайны для выявления проблем на ранних этапах.

5. Проводите регулярное тестирование

Регулярно проводите тестирование на проникновение и сканирование уязвимостей. Особое внимание уделяйте проверкам авторизации на уровне объектов — они не обнаруживаются автоматизированными методами.

6. Обучайте команды

Обучайте разработчиков принципам OWASP API Security Top 10. Понимание этих рисков должно быть частью культуры разработки, а не просто формальным требованием.

OWASP API Security Top 10 — это не просто список уязвимостей, а практический инструмент для выстраивания системной защиты API. Версия 2023 года отражает эволюцию ландшафта угроз: появление новых векторов атак (SSRF, неограниченный доступ к бизнес-потокам, небезопасное потребление API) и переосмысление существующих рисков.

Самой значимой проблемой остается авторизация — три из десяти рисков связаны именно с ней. BOLA (Broken Object Level Authorization) продолжает лидировать как самая распространенная и опасная уязвимость.

Для российских организаций OWASP API Security Top 10 становится не только международным стандартом, но и практическим руководством для выполнения требований ФСТЭК. Компании, внедряющие системную защиту на основе OWASP, снижают вероятность успешных атак на 76%.

Помните: безопасность API — это не разовое мероприятие, а непрерывный процесс. Регулярно обновляйте знания о новых угрозах, проводите аудиты и тестирования, обучайте команды. Только комплексный подход позволит защитить ваши API в современном цифровом мире.