04/09/2026

Защита API: что взламывают чаще всего и как этого избежать

API становятся главной целью атак хакеров, обогнав в списке уязвимостей традиционных лидеров, которыми являются браузеры и ОС. Одна из причин — все большее количество API-интеграций. Компании используют сотни API, а enterprise-сегмент полагается на тысячи внешних интеграций. Попытка охватить все возможности для атаки — это сложнейшая задача для ИБ.

На API приходится более половины всех эксплуатируемых уязвимостей, и их количество растет год от года. Главная цель атак на API — финансовый сектор. На банки в 2025 году пришлось 83% всех зарегистрированных атак на API, а хотя бы об одном инциденте за год сообщила практически каждая финансовая организация.

Успешные атаки обходятся в среднем в 700 тысяч долларов. Репутационные потери сложнее поддаются оценке, но также могут оказаться критическими. Подготовиться к атакам поможет понимание типовых уязвимостей в API. Большинство из них не меняется годами, но это не решает проблем их уязвимости.

Типичные уязвимости по OWASP API Top 10

Одним из авторитетнейших списков угроз является OWASP API Security Top 10. первая редакция OWASP TOP-10 API вышла в 2019 году, а в 2023 представили переработанную версию.

Угрозы ранжируются на основе частоты эксплуатации, широты распространения и тяжести возможного ущерба. Также списки формата “ТОП-10 уязвимостей” существуют для веб-приложений, API, а недавно вышла также подборка угроз для LLM.

Главные уязвимости API по OWASP в редакции 2023 года:
● API 1 — Нарушенная авторизация на уровне объекта;
● API 2 — Некорректная аутентификация;
● API 3 — Нарушенная авторизация на уровне свойств объекта;
● API 4 — Неограниченное потребление ресурсов;
● API 5 — Нарушенная авторизация на уровне функции;
● API 6 — Неограниченный доступ к чувствительным бизнес-процессам;
● API 7 — Подделка запросов на стороне сервера;
● API 8 — Ошибки конфигурации безопасности;
● API 9 — Неправильное управление активами;
● API 10 — Небезопасное использование сторонних API.

Проблемы с доступом. Авторизация и аутентификация

Для удобства угрозы API по версии OWASP можно разбить на три группы: проблемы с доступом, проблемы с расходом ресурсов и проблемы с настройками. Также это разделение примерно отражает распространенность уязвимостей.

Порядка 40% угроз приходится на проблемы с доступом — авторизацией и аутентификацией. Связанные с доступами угрозы занимают 4 из 5 мест в ТОП-5 угроз для API и являются важнейшими рубежами защиты от компрометации API.

Авторизацию и аутентификацию иногда путают даже разработчики, и прежде, чем погружаться в разбор, определимся с понятиями:

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

Проблемы аутентификации (OWASP API 2) возникают из-за традиционных и понятных причин: слишком простые пароли, слабые механизмы аутентификации, небрежное хранение секретов и использование устаревших токенов. Уязвимости на уровне авторизации устроены сложнее и требуют более сложных мер для защиты.

BOLA. Неизменная главная угроза

Самой распространенной уязвимостью списка OWASP является BOLA — нарушение авторизации на уровне объекта. В этом случае сервер не проверяет, принадлежит ли объект пользователю. Например, BOLA позволяет получить доступ к корзине с заказами, минуя проверку прав и авторизацию.

На BOLA приходится около 40% всех атак на API. Причина распространенности — человеческий фактор. В отличие от логики аутентификации, которая как правило долго остается неизменной, авторизацию для каждого нового типа объектов и действий приходится прописывать заново. Отсутствие ошибок сегодня не гарантирует, что они не появятся позже, при создании нового класса объектов.

Уязвимость BOLA может проявляться не только при чтении данных, но и при их создании, изменении или удалении. Проверки безопасности должны охватывать все возможные операции над объектом и обновляться вместе с изменениями бизнес-логики.

Нарушение авторизации на уровне свойств и функций

Уязвимости OWASP API 3 и API 5 объединяет выдача избыточных прав. В случае API 3 пользователь получает возможность читать или изменять поля объекта, которые ему не принадлежат. В примере с корзиной заказов, злоумышленник может установить скидку на заказ 100%, инициировать возврат средств или отредактировать не принадлежащий ему объект.

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

Бесконтрольный расход ресурсов и бюджета

Проблемы с API не ограничиваются присвоением прав и кражей данных. Атака может быть направлена на истощение ресурсов организации (API 4) или доступ к критичным бизнес-процессам (API 6).

Целью атаки по сценарию API 4 может стать любое потребляющее ресурсы действие, которое можно выполнить неограниченное количество раз. Уязвимость API 6 делает возможным доступ непосредственно к затратным бизнес-процессам и “сжиганию” бюджета организации.

Другие угрозы OWASP и инъекции кода

ТОП-10 замыкают угрозы подделки исходящих запросов сервера, ошибки конфигурации API, а также неаккуратное владение активами — забытые эндпоинты и устаревшие, но активные версии API.

Подделка запросов на стороне сервера— это один из самых разрушительных сценариев для API в облачной инфраструктуре. Атакующий может заставить сервер обратиться к метаданным облачного провайдера, извлекая IAM-токены и получая доступ к критическим данным. Эти уязвимости решаются инженерными методами, и для их обсуждения потребовался бы отдельный материал.

Уязвимость OWASP API 10, небезопасное использование сторонних API, относится к заражению через доверенные зависимости. Зараженные обновления партнеров способны масштабировать уязвимости на тысячи организаций и их клиентов. Мы посвятили теме атак на цепочки поставок отдельный материал.

Инъекции кода

Инъекции остаются одной из главных угроз для API и веб-безопасности в целом. К ним относятся фрагменты SQL-кода, команды ОС или другие инструкции, встроенные в пользовательский ввод и исполняемые сервером. Уязвимость исключили из редакции OWASP TOP-10 API 2023 и перенесли в общие угрозы веб-безопасности. Это не снизило ее актуальность для защиты API.

Единственной надежной защитой является параметризация запросов, исключающая команды, не соответствующие шаблону. Валидация по списку блокировки) — популярная полумера: ее можно обойти через нестандартный синтаксис или кодирование входных данных.

Базовые принципы защиты API

API невозможно изолировать от сети по определению, поэтому все способы защиты носят относительный характер. Снизить риск атаки позволяет соблюдение базовых принципов, исключающих или минимизирующих ущерб от атаки по различным сценариям OWASP.

Rate Limiting и ротация токенов

Не выставленное ограничение на частоту запросов делает возможным истощение ресурсов (OWASP API 4), подбор паролей (OWASP API 2), массовую отправку платежных запросов и регистрацию аккаунтов (OWASP API 6).

Лимиты необходимо выставлять на попытки регистрации, ввода пароля, отправку кодов подтверждения и другие критические операции. Автоматизированный поиск аномалий в поведении пользователей позволит пресечь злоупотребления на ранних стадиях.

Авторизация

Проверка ID пользователя помогают лишь от простейших атак. Запрос может быть перехвачен, а доступ к объекту выглядеть легитимным и не обнаруживаться сканерами. Самая важная практика защиты — явная сверка прав текущего пользователя и объекта на стороне сервера. Это единственный способ гарантировать, что подмена идентификатора не приведет к утечке данных.

Минимизация поверхности атаки

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

Логирование и поиск аномалий

Большинство атак обнаруживается не в момент взлома, а спустя недели. Подробные логи на каждом этапе позволяют провести расследование инцидента, оценить ущерб и устранить причины уязвимости. Для банков логирование особенно важно для выполнения требований регулятора.

Чек-лист безопасности API

Проверить готовность вашей инфраструктуры к атакам на API можно по списку. Он не исключает угрозу полностью, но помогает сделать риск контролируемым и предсказуемым, и критически снизить радиус поражения в случае успешной атаки.

● Аутентификация через URL или через внешние сервисы полностью исключена (OWASP API 2). Используются пароли и токены с коротким сроком жизни. HTTPS обязателен, а данные доступов защищены и не хранятся в коде.

● Авторизация проходит проверки при каждом запросе (OWASP API 1, 3 и 5). Используются непредсказуемые идентификаторы, например, UUID.

● Все API-эндпоинты задокументированы, устаревшие версии API отключены, а токены предыдущих версий аннулированы (OWASP API 9);

● Частота запросов ограничена на всех чувствительных процессах и действиях (OWASP API 4 и 6);

● Выставлены минимальные привилегии. Каждый токен имеет доступ только к своей части бизнес-логики (OWASP API 5);

● Выставлен запрет на получение заведомо неподходящих значений (OWASP API 3 и 7);

● Логируются запросы к эндпоинтам, ошибки авторизации (401 и 403), аномальный рост частоты запросов с одного IP (OWASP API 8);

● Настроен мониторинг, система автоматически проверяет резкие скачки запросов, цепочки вызовов и другие аномалии (OWASP API 4, 6, 8).
0%

Банк ГПБ (АО) использует файлы cookie. Подробная информация –
в правилах по обработке персональных данных. Вы можете запретить сохранение cookie в настройках своего браузера.