OWASP API Security Top 10 — отдельный рейтинг рисков для программных интерфейсов, который OWASP поддерживает параллельно с классическим OWASP Top 10 для веб-приложений. Актуальная версия — 2023 года. Она учитывает специфику REST, GraphQL и gRPC: авторизацию на уровне объектов, неограниченное потребление ресурсов, SSRF, небезопасное потребление внешних API. Для российских организаций этот рейтинг становится практическим чеклистом при реализации мер ФСТЭК №117, №21 и №239 на прикладном уровне. В этой статье — полный разбор всех десяти категорий OWASP API Top 10 2023 с привязкой к CWE, записям БДУ ФСТЭК и модулям платформы КиберОснова SGRC.
TL;DR: OWASP API Security Top 10 (версия 2023) — единственный международный рейтинг десяти самых опасных рисков для REST и GraphQL API. Лидер — API1 (BOLA, Broken Object Level Authorization), далее Broken Authentication, Broken Object Property Level Authorization. Для российских организаций каждая из 10 категорий маппится на меры ФСТЭК групп ИАФ, УПД, ЗИС, АНЗ, ИНВ из приказов №117, №21, №239.
Материал рассчитан на специалистов ИБ, отвечающих за безопасность API, инженеров DevSecOps, архитекторов продуктов и аудиторов, работающих с информационными системами под требованиями ФСТЭК. Большинство современных ГИС, ИСПДн и объектов КИИ используют API для обмена данными, и именно там чаще всего обнаруживаются критичные уязвимости. OWASP API Security Top 10 2023 систематизирует работу по безопасности API и связывает её с мерами защиты информации ФСТЭК — группами ИАФ, УПД, ЗИС, АНЗ и ИНВ.
Через калькулятор CVSS v4.0 можно рассчитать критичность найденной API-уязвимости и определить SLA на устранение по приказу ФСТЭК №117. А интерактивная таблица на странице OWASP Top 10 — хаб показывает связь категорий OWASP с CWE-идентификаторами и записями в БДУ ФСТЭК.
Что такое OWASP API Security Top 10 и зачем он нужен
API Security Project — самостоятельное направление OWASP. Первая версия рейтинга вышла в 2019 году, а в 2023 OWASP выпустил обновлённую редакцию, учитывающую рост атак на BOLA, BFLA и SSRF. В отличие от классического OWASP Top 10, здесь категории называются API1–API10 и ориентированы именно на серверную логику интерфейсов: авторизацию запросов, валидацию параметров, управление ресурсами, безопасное взаимодействие с внешними сервисами.
Почему отдельный рейтинг для API
Классический OWASP Top 10 составлен на данных о веб-приложениях в целом, но API имеют свою специфику. Во-первых, атакующий напрямую обращается к бизнес-логике: нет промежуточного UI, который бы фильтровал входные данные. Во-вторых, API часто работают с идентификаторами объектов в URL или теле запроса — это открывает путь к IDOR и BOLA. В-третьих, современные API отдают и принимают JSON с десятками полей, где легко сделать ошибку массового присвоения атрибутов. Эти риски плохо укладываются в рамки обычного Top 10, поэтому OWASP выделил их в отдельный список.
Связь с российским регулированием
ФСТЭК России в приказах №117, №21 и №239 требует реализации мер, которые напрямую покрывают риски OWASP API Security Top 10. Группа мер ИАФ (идентификация и аутентификация) закрывает категории API2 (Broken Authentication). Группа УПД (управление доступом) — API1, API3, API5 (авторизация на уровне объектов, свойств и функций). Группа ЗИС (защита информационной системы) — API4 (rate limiting), API7 (SSRF), API8 (конфигурация). Группа АНЗ (анализ уязвимостей) — выявление всех типов API-уязвимостей через сканирование. Группа ИНВ (инвентаризация) — API9 (управление реестром API). Таким образом, OWASP API Top 10 работает как практический чеклист для проверки полноты реализации мер ФСТЭК на уровне программных интерфейсов.
Как рейтинг связан с CWE и БДУ ФСТЭК
Каждая категория OWASP API Top 10 сопоставляется с набором CWE (Common Weakness Enumeration). Например, API1 BOLA покрывается CWE-639, API2 — CWE-287 и CWE-307, API4 — CWE-770. Классические инъекции (SQLi, XSS, Command Injection) формально относятся к обычному OWASP Top 10, но в API-контексте встречаются не реже — подробный разбор SQL-инъекций с мерами ФСТЭК и SLA по приказу №117 разобран в статье Защита от SQL-инъекций (CWE-89). Реестр БДУ ФСТЭК классифицирует каждую зафиксированную уязвимость по CWE, поэтому через платформу КиберОснова легко подсчитать, сколько записей реестра относится к каждой категории OWASP и где сосредоточены наибольшие риски для конкретной организации.
API1:2023 — Broken Object Level Authorization (BOLA)
Категория занимает первое место в OWASP API Security Top 10 2023 — именно BOLA обнаруживается чаще всего при тестировании API. В классическом OWASP Top 10 она соответствует части Broken Access Control.
Суть проблемы
Broken Object Level Authorization возникает, когда API принимает идентификатор объекта в запросе и возвращает данные без проверки, принадлежит ли объект текущему пользователю. Атакующий перебирает идентификаторы или использует чужой и получает данные, к которым не должен иметь доступа. Это ключевой риск для любых API с ролями и разграничением доступа — от банковских систем до медицинских сервисов.
Пример уязвимости
Пользователь авторизуется в API мобильного банка и получает JWT-токен. Далее он делает запрос:
GET /api/v1/accounts/10045/transactions
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
API возвращает транзакции по счёту 10045 — счёту атакующего. Перебирая числа /api/v1/accounts/10046/..., /api/v1/accounts/10047/..., атакующий получает выписки по чужим счетам: сервер проверяет только валидность токена, но не проверяет, что счёт принадлежит владельцу токена. Этот класс атак называется IDOR (Insecure Direct Object Reference).
Связанные CWE
- CWE-639 — авторизация на основе данных, контролируемых пользователем
- CWE-284 — некорректный контроль доступа
- CWE-285 — некорректная авторизация
Меры ФСТЭК
- УПД.2 — разграничение доступа субъектов к объектам
- УПД.4 — разделение полномочий
- УПД.13 — контроль доступа через интерфейсы управления
- РСБ.1 — регистрация событий доступа к защищаемым объектам
Как КиберОснова помогает
Модуль Аудит ИБ проверяет реализацию меры УПД.2 в информационной системе: наличие авторизации на уровне объектов, покрытие API-эндпоинтов контролем доступа, корректность связки «пользователь → объект». Результаты аудита фиксируются в платформе с назначением ответственных и сроков устранения несоответствий. Это та же дисциплина, что OWASP рекомендует для защиты от BOLA, только привязанная к российским нормативным группам мер.
API2:2023 — Broken Authentication
Вторая категория рейтинга — сломанная аутентификация. Сюда входят слабые пароли, отсутствие защиты от перебора, небезопасное хранение токенов, некорректная реализация OAuth 2.0 и JWT.
Суть проблемы
API принимает запросы от неаутентифицированных пользователей там, где должна требовать аутентификацию; или механизм аутентификации реализован некорректно — токены можно подделать, сессии не инвалидируются при выходе, нет ограничения попыток входа. Атакующий получает доступ под чужой учётной записью — через brute force, credential stuffing или подделку токена.
Пример уязвимости
API использует JWT с алгоритмом подписи HS256 и общим секретным ключом. Однако эндпоинт /api/v1/auth/login не ограничивает количество попыток входа по IP или логину. Атакующий запускает перебор 10 000 популярных паролей за несколько минут:
POST /api/v1/auth/login
Content-Type: application/json
{"username": "admin", "password": "Password123"}
Отсутствует задержка между попытками, нет капчи, нет блокировки аккаунта после N неудач — атакующий подбирает пароль администратора. Это типичная реализация Broken Authentication.
Связанные CWE
- CWE-287 — некорректная аутентификация
- CWE-307 — неограниченное число попыток аутентификации
- CWE-798 — жёстко закодированные учётные данные
- CWE-522 — недостаточная защита учётных данных
Меры ФСТЭК
- ИАФ.1 — идентификация и аутентификация пользователей
- ИАФ.3 — управление идентификаторами
- ИАФ.4 — управление средствами аутентификации
- ИАФ.6 — защита обратной связи при вводе аутентификационной информации
- ИАФ.7 — идентификация и аутентификация при удалённом доступе
Как КиберОснова помогает
Модуль БДУ ФСТЭК ежедневно получает новые записи об уязвимостях аутентификации в распространённых библиотеках и фреймворках. Если организация использует, например, уязвимую версию Spring Security или Passport.js, соответствующая запись в БДУ автоматически сопоставляется с ИТ-активом, рассчитывается CVSS и назначается SLA на обновление по приказу №117. Параллельно модуль Аудит ИБ проверяет реализацию группы мер ИАФ — наличие многофакторной аутентификации, политики паролей, защиту от перебора.
API3:2023 — Broken Object Property Level Authorization
Новая категория в версии 2023 года. Она объединяет два более ранних риска: Excessive Data Exposure (избыточная выдача данных) и Mass Assignment (массовое присвоение атрибутов).
Суть проблемы
API возвращает или принимает больше полей объекта, чем положено для текущего пользователя. Пример избыточной выдачи: эндпоинт /api/users/{id} возвращает весь JSON пользователя, включая поля passwordHash, isAdmin, internalNotes — даже если клиент (например, мобильное приложение) никогда их не отображает. Пример массового присвоения: форма редактирования профиля передаёт весь JSON на сервер, а сервер автоматически маппит поля в модель — атакующий добавляет в запрос поле "isAdmin": true и получает административные права.
Пример уязвимости
Пользователь обычного уровня отправляет запрос на обновление своего профиля:
PATCH /api/v1/users/me
Content-Type: application/json
{"displayName": "Alice", "email": "alice@example.com", "role": "admin"}
Сервер использует автоматическое связывание параметров (model binding) и записывает все поля, пришедшие в теле запроса, в запись БД. Поле role не входит в официальную спецификацию API, но бэкенд не фильтрует входные данные — пользователь становится администратором.
Связанные CWE
- CWE-915 — некорректное управление изменением атрибутов объекта
- CWE-213 — раскрытие чувствительной информации в сообщениях
- CWE-200 — раскрытие чувствительной информации
Меры ФСТЭК
- УПД.2 — разграничение доступа к атрибутам объектов
- УПД.4 — разделение полномочий между пользователями и администраторами
- ЗИС.17 — фильтрация содержимого информационных потоков
- ОЦЛ.5 — контроль целостности входящих данных
Как КиберОснова помогает
В модуле Аудит ИБ проверка реализации меры УПД.2 на API-уровне включает анализ схем JSON-ответов и тел запросов: какие поля объекта клиент может читать, какие редактировать, что должно быть скрыто. Несоответствия фиксируются как несоблюдения и передаются в работу. Для модели угроз КиберОснова хранит связку «API-эндпоинт → обрабатываемый объект → разрешённые атрибуты» как часть модели информационной системы.
API4:2023 — Unrestricted Resource Consumption
Четвёртая категория — неограниченное потребление ресурсов. Сюда входят отсутствие rate limiting, DoS через тяжёлые запросы, утечка памяти и безудержное потребление CPU, сетевого трафика или внешних платных сервисов (SMS, email).
Суть проблемы
API принимает неограниченное число запросов от одного клиента, возвращает коллекции без пагинации, выполняет тяжёлые операции без контроля нагрузки. Атакующий устраивает отказ в обслуживании или разоряет компанию на внешних сервисах: каждая отправка SMS через API стоит денег, и если эндпоинт восстановления пароля не лимитирован, злоумышленник отправляет миллионы SMS за считанные часы.
Пример уязвимости
Эндпоинт экспорта отчётов принимает параметр количества строк без ограничения:
GET /api/v1/reports/export?rows=1000000&format=xlsx
Сервер формирует Excel-файл на миллион строк, занимает 4 ГБ памяти на несколько минут, блокирует другие запросы. Атакующий запускает 20 параллельных запросов с разных IP — сервис полностью ложится.
Связанные CWE
- CWE-770 — неограниченное выделение ресурсов
- CWE-400 — неконтролируемое потребление ресурсов
- CWE-799 — некорректный контроль частоты взаимодействия
Меры ФСТЭК
- ЗИС.19 — защита от атак типа «отказ в обслуживании»
- ЗИС.17 — фильтрация информационных потоков
- РСБ.1 — регистрация событий, влияющих на доступность
- АНЗ.1 — выявление уязвимостей, связанных с DoS
Как КиберОснова помогает
Мера ЗИС.19 — одна из ключевых для организаций, работающих с внешними API. КиберОснова SGRC хранит реестр мер защиты с указанием ответственных и статусов внедрения: внесена ли политика rate limiting на уровне API-gateway, реализована ли пагинация в коллекциях, настроены ли лимиты на размер тела запроса. Модуль Управление рисками оценивает остаточный риск DoS на основе полноты покрытия меры ЗИС.19 и включает его в карту рисков организации.
API5:2023 — Broken Function Level Authorization
Категория о нарушении авторизации на уровне функций. В отличие от API1 (BOLA), здесь речь не о конкретном объекте, а о всей функции — например, об административном эндпоинте, доступном обычному пользователю.
Суть проблемы
API содержит функции разных уровней привилегий — публичные, пользовательские, административные. При этом контроль доступа к административным функциям либо отсутствует, либо реализован на клиенте (например, UI скрывает кнопку «Удалить пользователя» у обычных пользователей, но сам эндпоинт /api/admin/users/delete не проверяет роль). Атакующий напрямую обращается к эндпоинту в обход UI и выполняет административные действия.
Пример уязвимости
Приложение имеет административную функцию удаления пользователей. В клиентском коде эта кнопка отображается только для admin, но API-эндпоинт принимает запросы от любого аутентифицированного пользователя:
DELETE /api/v1/admin/users/42
Authorization: Bearer <user-token>
Сервер проверяет только валидность токена, но не проверяет роль. Атакующий, имея обычный пользовательский аккаунт, удаляет произвольных пользователей из системы.
Связанные CWE
- CWE-862 — отсутствие авторизации
- CWE-863 — некорректная авторизация
- CWE-285 — некорректная авторизация
Меры ФСТЭК
- УПД.4 — разделение полномочий между пользователями и администраторами
- УПД.5 — запрет действий, не разрешённых политикой доступа
- УПД.6 — ограничение неуспешных попыток доступа
- РСБ.1 — регистрация действий административного характера
Как КиберОснова помогает
В рамках меры УПД.4 платформа фиксирует перечень административных ролей, список эндпоинтов, доступных каждой роли, и ответственных за поддержку этой матрицы. В модуле Аудит ИБ можно запустить проверку на соответствие матрицы реальной реализации — с выгрузкой результатов в отчёт для руководства или проверки ФСТЭК.
Закрываете OWASP API Top 10 вручную? КиберОснова SGRC автоматизирует весь цикл защиты API: синхронизация с БДУ ФСТЭК, сопоставление уязвимостей с API-активами, SLA-контроль по приказу №117, аудит мер ИАФ/УПД/ЗИС/АНЗ. Полный маппинг категорий API1–API10 на группы мер ФСТЭК — на одной дашборд-странице. Запросить демо →
API6:2023 — Unrestricted Access to Sensitive Business Flows
Новая категория в 2023 году. Она описывает злоупотребление легитимными бизнес-процессами через API — без технической уязвимости, но с разрушительными последствиями для бизнеса.
Суть проблемы
API реализует бизнес-процесс, который работает корректно для обычных пользователей, но позволяет массовое автоматизированное использование. Например: покупка лимитированного товара, бронирование мест, регистрация аккаунтов, подбор купонов. Атакующий запускает бота, который совершает тысячи легитимных операций за секунды — скупает весь товар, забивает брони, создаёт мусорные аккаунты. Формально это не уязвимость кода, но реальный бизнес-ущерб огромен.
Пример уязвимости
Интернет-магазин запускает распродажу ограниченной серии товара. API-эндпоинт /api/v1/orders/create не отличает человека от бота: нет капчи, нет задержек, нет проверки аномальных паттернов поведения. Бот совершает 500 покупок за минуту, выкупает весь запас и перепродаёт его на вторичном рынке.
Связанные CWE
- CWE-840 — ошибки в логике бизнес-процессов
- CWE-799 — некорректный контроль частоты взаимодействия
- CWE-770 — неограниченное потребление ресурсов
Меры ФСТЭК
- ЗИС.19 — защита от DoS на уровне бизнес-логики
- ЗИС.17 — фильтрация информационных потоков
- РСБ.1 — регистрация событий бизнес-процессов
Как КиберОснова помогает
Категория API6 относится не столько к технической уязвимости, сколько к риск-менеджменту. В модуле Управление рисками фиксируются бизнес-процессы, критичные для организации, и оцениваются сценарии злоупотребления ими. Для каждого сценария назначаются компенсирующие меры: капча, поведенческий анализ, ограничение по IP, ручная верификация аномальных операций.
API7:2023 — Server Side Request Forgery (SSRF)
Server Side Request Forgery — атака, при которой API выполняет запрос к URL, указанному пользователем. Категория появилась в OWASP Top 10 2021 и теперь отдельно вынесена в API Top 10 2023 из-за специфики микросервисных архитектур.
Суть проблемы
API принимает от пользователя URL (например, для загрузки изображения из интернета или интеграции с внешним сервисом) и выполняет HTTP-запрос к этому URL со стороны сервера. Атакующий указывает внутренний адрес — http://localhost:8080/admin, http://169.254.169.254/latest/meta-data/ (метаданные AWS), file:///etc/passwd. API выполняет запрос, и атакующий получает доступ к внутренним сервисам или чувствительным данным.
Пример уязвимости
Эндпоинт импорта изображения по URL:
POST /api/v1/images/import
Content-Type: application/json
{"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}
Сервер загружает содержимое по указанному адресу и возвращает его в ответе. Атакующий получает учётные данные роли EC2-инстанса — это критическая утечка секретов облачной инфраструктуры. Для защиты необходимо whitelist URL-схем, запрет на запросы к private/loopback/metadata-адресам, использование резолвера DNS с фильтрацией.
Связанные CWE
- CWE-918 — Server-Side Request Forgery
- CWE-20 — некорректная валидация ввода
- CWE-601 — открытое перенаправление
Меры ФСТЭК
- ЗИС.17 — фильтрация содержимого информационных потоков
- ЗИС.20 — защита периметра информационной системы
- ОЦЛ.5 — контроль целостности входящих данных
- АНЗ.1 — выявление SSRF-уязвимостей на этапе сканирования
Как КиберОснова помогает
Мера ЗИС.20 (защита периметра) особенно актуальна для облачных инсталляций: она требует контроля взаимодействия с внешними сервисами. В платформе фиксируется перечень разрешённых внешних адресов и политик исходящего трафика. Модуль БДУ ФСТЭК отслеживает публикацию новых SSRF-уязвимостей в используемых библиотеках (например, в HTTP-клиентах популярных языков) и автоматически создаёт задачи на обновление по приказу №117.
API8:2023 — Security Misconfiguration
Категория о неверной конфигурации безопасности API и инфраструктуры вокруг него. Именно эту категорию чаще всего обнаруживают пентестеры — её исправление не требует изменений кода, но даёт быстрый эффект.
Суть проблемы
API и его окружение настроены с ошибками: включены отладочные эндпоинты в продакшене, не установлены security-заголовки, используется устаревшая версия TLS, разрешены опасные HTTP-методы, CORS настроен слишком разрешающе (Access-Control-Allow-Origin: *), выключено шифрование трафика между сервисами, открыт доступ к порту администрирования извне.
Пример уязвимости
API-сервис в продакшене случайно оставили с включённым Swagger UI на публичном URL:
GET /api/v1/swagger-ui.html
Страница показывает полную документацию всех эндпоинтов, включая внутренние и административные. Из интерфейса Swagger атакующий тестирует эндпоинты, перебирает параметры и обнаруживает слабые места. Дополнительно — настройки CORS разрешают запросы с любого домена, что позволяет атаке из стороннего веб-приложения жертвы.
Связанные CWE
- CWE-16 — ошибки конфигурации
- CWE-933 — неверная конфигурация безопасности
- CWE-1004 — отсутствие флага HttpOnly у чувствительных cookies
- CWE-942 — излишне разрешающие настройки CORS
Меры ФСТЭК
- ЗИС.3 — криптографическая защита передаваемой информации
- ЗИС.7 — применение СКЗИ при передаче данных
- АНЗ.2 — контроль установки обновлений безопасности
- ОПС.2 — управление конфигурацией информационной системы
Как КиберОснова помогает
Группа мер ОПС (обеспечение безопасного программного обеспечения) требует управления конфигурацией: ведение эталонных настроек, контроль отклонений, регистрация изменений. В модуле Аудит ИБ проверки конфигурации API-слоя формализуются как чек-листы: включён ли HTTPS, установлены ли security-заголовки, выключены ли тестовые эндпоинты, корректны ли настройки CORS. Результаты сохраняются в истории аудитов организации.
API9:2023 — Improper Inventory Management
Девятая категория — неверное управление реестром API. Проблема характерна для крупных организаций с десятками сервисов: часть API забыта, часть задокументирована некорректно, часть работает в устаревших версиях.
Суть проблемы
Организация развернула множество API-версий и окружений — v1, v2, v3, staging, dev, legacy. Часть из них уже не поддерживается, но продолжает работать и принимать запросы. Старая версия API может использовать уязвимую библиотеку, устаревшую схему аутентификации или раскрывать эндпоинты, которые удалены в новой версии. Атакующие находят такие забытые API через сканирование поддоменов или перебор версий и атакуют их.
Пример уязвимости
Компания выкатила v2 API с исправленной авторизацией, но v1 работает и обслуживает старых клиентов. В v1 сохраняется BOLA-уязвимость, которую официально «уже исправили». Атакующий замечает обращение api-v1.example.com в истории коммитов открытого репозитория компании и атакует устаревшую версию:
GET /api/v1/users/42/documents
Authorization: Bearer <any-valid-token>
Связанные CWE
- CWE-1059 — недостаточная документация на техническую систему
- CWE-1053 — отсутствие управления жизненным циклом
- CWE-1061 — недостаточная инкапсуляция
Меры ФСТЭК
- ИНВ.1 — инвентаризация компонентов информационной системы
- ИНВ.2 — идентификация и учёт пользователей и их прав
- ОПС.1 — управление установленным ПО
- АНЗ.4 — контроль обновлений компонентов системы
Как КиберОснова помогает
Группа мер ИНВ (инвентаризация) — один из наиболее слабо закрытых участков в российских организациях. Модуль инвентаризации КиберОснова хранит реестр ИТ-активов, который включает не только серверы и рабочие станции, но и логические сущности — API-сервисы, их версии, окружения. Каждому API присваивается ответственный, срок вывода из эксплуатации и связка с текущей документацией. Подробнее о правильной инвентаризации — в статье Меры защиты информации ФСТЭК.
API10:2023 — Unsafe Consumption of APIs
Десятая категория — небезопасное потребление внешних API. Раньше разработчики не доверяли данным пользователя, но доверяли данным, приходящим от сторонних сервисов. OWASP фиксирует, что это уже не работает: атака на внешний API превращается в атаку на ваше приложение.
Суть проблемы
Ваш API интегрируется с внешним сервисом — платёжной системой, CRM, геолокацией, контентом от партнёра. Вы доверяете ответам этого сервиса и не валидируете их. Если внешний сервис скомпрометирован или злонамеренный — он может вернуть вам данные, которые приведут к уязвимости: например, JSON с внедрённым объектом, который после десериализации выполнит произвольный код; или URL, на который вы перенаправите пользователя без проверки. Также сюда входит обработка ошибок внешнего API: атакующий может спровоцировать внешний сервис на ошибку и заставить ваш API раскрыть секреты.
Пример уязвимости
Приложение использует Java с библиотекой Jackson и принимает ответ от стороннего API в JSON. Конфигурация десериализации разрешает enableDefaultTyping, что позволяет сторонней системе в теле ответа указать класс Java для инстанциации. Злонамеренный внешний сервис возвращает:
{"@class": "org.apache.commons.beanutils.BeanComparator", ...}
Сервер десериализует объект и запускает выполнение кода на своей стороне — это классическая Java Deserialization RCE, соответствующая CWE-502.
Связанные CWE
- CWE-502 — десериализация ненадёжных данных
- CWE-20 — некорректная валидация ввода
- CWE-95 — некорректная нейтрализация кода
Меры ФСТЭК
- ЗИС.17 — фильтрация содержимого информационных потоков
- ЗИС.20 — защита периметра системы при взаимодействии с внешними сервисами
- ОЦЛ.5 — контроль целостности входящих данных
- АНЗ.1 — выявление уязвимостей десериализации и инъекций
Как КиберОснова помогает
Для API10 ключевой является полнота реализации группы мер ЗИС. Платформа ведёт реестр внешних интеграций организации: какой API, какой сервис, какой класс обрабатываемых данных, какие меры защиты применяются. При публикации в БДУ ФСТЭК уязвимости в распространённых библиотеках десериализации (Jackson, Gson, Fastjson, pickle) модуль БДУ ФСТЭК сопоставляет запись с ИТ-активами и создаёт задачу на обновление с приоритетом по CVSS.
Мониторинг API-уязвимостей через SGRC
Ручная проверка API на все 10 категорий OWASP — задача на недели работы квалифицированного пентестера. SGRC-платформа КиберОснова автоматизирует цикл выявления и устранения API-уязвимостей и связывает его с требованиями ФСТЭК.
Шаг 1. Реестр API как часть инвентаризации
В модуле инвентаризации фиксируются все API организации: внутренние и внешние, продакшен и staging, с указанием версий и технологического стека. Это закрывает категорию API9 и меру ИНВ.1.
Шаг 2. Сопоставление CWE → БДУ → активы
Модуль БДУ ФСТЭК ежедневно синхронизируется с реестром bdu.fstec.ru и получает новые записи. Каждая запись классифицирована по CWE, и платформа автоматически маппит её на категории OWASP API Top 10. Если уязвимость относится к используемой API-библиотеке, создаётся задача на обновление.
Шаг 3. SLA по приказу №117
Для каждой уязвимости рассчитывается SLA на устранение по CVSS-формуле из приказа ФСТЭК №117: от 24 часов для критичных до 30 дней для средних. Специалист ИБ получает приоритизированный backlog вместо сырого потока данных.
Шаг 4. Аудит мер ФСТЭК как чек-лист OWASP
Модуль Аудит ИБ позволяет запускать проверки полноты реализации мер ИАФ, УПД, ЗИС, АНЗ, ОПС — тех самых групп, что покрывают категории API1–API10. Результаты аудита фиксируются в истории организации и используются при подготовке к проверкам ФСТЭК и аттестации ИС.
Шаг 5. Отчёты и карта рисков
Модуль Управление рисками формирует карту рисков с учётом остаточных рисков по каждой категории OWASP: сколько уязвимостей обнаружено, сколько устранено, сколько просрочено. Отчёты выгружаются для руководства и для регулятора.
Запустить мониторинг API-уязвимостей с привязкой к ФСТЭК и БДУ можно, запросив демо КиберОснова SGRC.
FAQ
Что такое OWASP API Security Top 10 и чем он отличается от обычного OWASP Top 10?
OWASP API Security Top 10 — отдельный рейтинг десяти критичных рисков для программных интерфейсов, который OWASP поддерживает параллельно с классическим OWASP Top 10. Актуальная версия — 2023 года. В отличие от обычного OWASP Top 10, здесь категории называются API1–API10 и описывают риски именно для API: авторизацию на уровне объектов и функций, сломанную аутентификацию, неограниченное потребление ресурсов, SSRF, небезопасное потребление внешних API. Эти риски плохо укладываются в рамки классического рейтинга, поэтому OWASP выделил их в отдельный список для специалистов, отвечающих за безопасность REST, GraphQL и gRPC API.
Как OWASP API Top 10 связан с приказами ФСТЭК №117, №21 и №239?
ФСТЭК России не ссылается на OWASP API Top 10 напрямую, но меры защиты из приказов №117, №21 и №239 фактически покрывают эти риски. Группа мер ИАФ (идентификация и аутентификация) закрывает API2 (Broken Authentication). Группа УПД (управление доступом) — API1, API3, API5. Группа ЗИС (защита информационной системы) — API4, API7, API8. Группа АНЗ (анализ уязвимостей) — выявление всех типов API-уязвимостей. Группа ИНВ (инвентаризация) — API9. Таким образом, OWASP API Top 10 служит практическим чеклистом для проверки полноты реализации мер ФСТЭК на уровне программных интерфейсов.
Что такое BOLA и почему это самая частая уязвимость API?
BOLA (Broken Object Level Authorization) — уязвимость, при которой API возвращает данные объекта без проверки, принадлежит ли этот объект текущему пользователю. Пример: пользователь обращается к /api/orders/12345 и получает свой заказ, меняет идентификатор на /api/orders/12346 и получает чужой заказ. API проверяет только аутентификацию (валидность токена), но не авторизацию на уровне конкретного объекта. BOLA занимает первое место в OWASP API Top 10 2023, потому что большинство разработчиков помнят о проверке токена, но забывают про связку «пользователь → объект». Меры группы УПД из приказов ФСТЭК требуют именно такого разграничения доступа.
Как защититься от SSRF-атак на API?
Защита от SSRF (Server-Side Request Forgery) требует комплекса мер. Во-первых, никогда не принимайте произвольные URL от пользователя: используйте whitelist разрешённых адресов. Во-вторых, запретите запросы к приватным IP-диапазонам, loopback (127.0.0.1), link-local (169.254.0.0/16), метаданным облачных провайдеров. В-третьих, используйте HTTP-клиент с поддержкой фильтрации резолвинга DNS. В-четвёртых, запретите небезопасные схемы — file://, gopher://, dict://. На уровне требований ФСТЭК SSRF закрывается мерами ЗИС.17, ЗИС.20 и ОЦЛ.5. Модуль БДУ ФСТЭК в КиберОснова отслеживает публикации новых SSRF-уязвимостей в библиотеках HTTP-клиентов.
Что такое Mass Assignment и как от него защититься?
Mass Assignment (массовое присвоение атрибутов) — уязвимость категории API3:2023. Она возникает, когда API автоматически маппит все поля из тела запроса на свойства объекта в БД. Атакующий добавляет в запрос поле isAdmin: true или role: admin и через обычный endpoint редактирования профиля получает административные права. Защита: использовать явные DTO (Data Transfer Object) с whitelist разрешённых полей, запрещать автоматический model binding всех атрибутов, валидировать JSON-схему входящего запроса, разделять admin-атрибуты от пользовательских на уровне отдельных эндпоинтов. Это реализует меру УПД.2 из приказов ФСТЭК.
Почему важно инвентаризировать API и как это связано с API9?
Категория API9 (Improper Inventory Management) описывает риск, когда в организации работают забытые API-версии, тестовые окружения и устаревшие эндпоинты. Атакующие находят их через сканирование поддоменов и версий и атакуют — старые версии часто содержат уязвимости, давно исправленные в актуальной. Инвентаризация API решает проблему: все эндпоинты зарегистрированы, каждому назначен владелец, определён срок вывода из эксплуатации, ведётся актуальная документация. На уровне ФСТЭК это мера ИНВ.1 (инвентаризация компонентов ИС) и ОПС.1 (управление установленным ПО). В КиберОснова API-сервисы хранятся в реестре ИТ-активов наравне с серверами.
Как КиберОснова SGRC автоматизирует защиту API по OWASP?
Платформа реализует полный цикл от выявления до устранения API-уязвимостей. Модуль БДУ ФСТЭК ежедневно синхронизируется с реестром bdu.fstec.ru и получает новые записи с CWE-классификацией, которая маппится на категории API1–API10. Уязвимости сопоставляются с реестром ИТ-активов организации, включая API-сервисы. Для каждой рассчитывается SLA на устранение по CVSS-формуле из приказа №117 — от 24 часов для критичных до 30 дней для средних. Модуль Аудит ИБ запускает проверки полноты реализации мер ИАФ, УПД, ЗИС, АНЗ, ОПС, которые закрывают все 10 категорий OWASP. Модуль Управление рисками формирует карту рисков и отчёты для руководства и регулятора.
Какие CWE входят в OWASP API Top 10 2023?
Каждая категория OWASP API Top 10 покрывает несколько CWE. API1 BOLA — CWE-639, CWE-284, CWE-285. API2 Broken Authentication — CWE-287, CWE-307, CWE-798, CWE-522. API3 Broken Object Property Level Authorization — CWE-915, CWE-213, CWE-200. API4 Unrestricted Resource Consumption — CWE-770, CWE-400, CWE-799. API5 Broken Function Level Authorization — CWE-862, CWE-863, CWE-285. API6 Unrestricted Access to Sensitive Business Flows — CWE-840, CWE-799, CWE-770. API7 SSRF — CWE-918, CWE-20, CWE-601. API8 Security Misconfiguration — CWE-16, CWE-933, CWE-942. API9 Improper Inventory Management — CWE-1059, CWE-1053, CWE-1061. API10 Unsafe Consumption of APIs — CWE-502, CWE-20, CWE-95. Все эти CWE представлены в реестре БДУ ФСТЭК и доступны для поиска на сайте КиберОснова.
