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

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

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

Ключевые методы атак на API

Сообщество OWASP мониторит риски API и обновляет список угроз в виде OWASP API Security Top 10. Хотя последний рейтинг выпустили в 2023 году, он до сих пор не теряет актуальности. Половина всех уязвимостей в списке OWASP связана с аутентификацией и авторизацией (логины, пароли, токены).

И так посмотрим, как трансформировались техники атак на API, и какие инциденты всплывали в публичном поле за последние несколько лет.

API1: Broken Object Level Authorization (ex IDOR — Insecure Direct Object Reference)

Суть уязвимости. Система контролирует, что пользователь аутентифицирован, но не проверяет, имеет ли он право работать именно с запрашиваемым объектом. Злоумышленнику достаточно изменить идентификатор в запросе, чтобы получить доступ к конфиденциальным данным.

BOLA не случайно в топе OWASP. Согласно последним исследованиям Salt Security на эту уязвимость приходится 27% всех атак на API.

Примеры атак. Первый инцидент произошёл с дилерским центром Volkswagen в Индии. В приложении для владельцев автомобилей обнаружили критическую BOLA-уязвимость. Чтобы зарегистрировать подержанный авто, нужно было ввести 4-значный код подтверждения. Система не ограничивала количество попыток, и скрипт перебирал все 10 тыс. комбинаций за секунды. Зная VIN-номер автомобиля, злоумышленник получал полный профиль владельца: историю обслуживания, телеметрию и текущее местоположение.

McDonald’s также столкнулся с атакой, включающей элементы BOLA. Компания использовала платформу найма, разработанную сторонним вендором. За счёт слабых или дефолтных учётных данных и манипуляций с идентификаторами, увидеть чужие персданные можно было, просто меняя ID соискателя в адресе страницы. В ходе атаки буквально за 30 минут были получены 64 млн резюме.

API2: Broken Authentication

Суть уязвимости. За счёт слабой или неправильно настроенной аутентификации злоумышленники могут выдавать себя за законных пользователей, получая полный доступ к их учёткам. Поводом для компрометации может послужить всё. Например, слабые токены и отсутствие проверки подписи или ограничений на попытки входа.

Примеры атак. Разработчик xAI случайно выложил на GitHub приватный ключ, дающий доступ к LLM SpaceX и Tesla. Ключ был доступен целых два месяца. Любой желающий мог запрашивать данные у более чем 60 приватных LLM, содержащих корпоративные данные. Подобный инцидент представляет собой классический пример утечки секретов. Причём утечки можно было избежать, если бы компания заранее позаботилась о базовых проверках безопасности в пайплайне разработки.

API3: Broken Object Property Level Authorization (BOPLA)

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

Примеры атак. В Joplin Server нашли уязвимость CVE-2025-27134 из-за которой, любой пользователь мог отправить PATCH на /api/users/:id, подставить is_admin=1 и сразу получить админские права. Сервер нормально проверял доступ к самому объекту («пользователь»), но совершенно не следил за тем, какие именно поля ему разрешено менять.

API4: Unrestricted Resource Consumption

Суть уязвимости. Если API не накладывает ограничения на потребление ресурсов (количество запросов, объём данных, время выполнения операций и т.п.), то злоумышленники могут исчерпать CPU, память, пропускную способность сети или нагрузить базу данных так, что сервис упадёт или серьёзно деградирует. В результате простоя компания потеряет деньги и испортит репутацию.

Примеры атак. Уязвимость CVE-2025-8014 в GitLab затронула GraphQL-эндпоинты. Злоумышленник собирал «тяжёлый» запрос, который проходил валидацию и истощал ресурсы сервиса. По сути, один неограниченный запрос к API приводил к тому, что сервис просто ложился. Кейс лишний раз демонстрирует, что без жёсткого контроля за сложностью запросов даже один неосторожный вызов может стать точкой отказа системы.

API5: Broken Function Level Authorization (BFLA)

Суть уязвимости. Возникает, когда проверка ролей на уровне эндпоинта либо вовсе не настроена, либо реализована с ошибками. В итоге обычный пользователь может вызывать функции, предназначенные для админов. Например, вызов эндпоинта DELETE /api/admin/users/{id} заставит API без каких-либо проверок удалить учётки других пользователей, включая самих администраторов.

Примеры атак. В Cisco Data Center Network Manager уязвимость CVE-2020-3386 в REST API позволяла аутентифицированному пользователю с низкими привилегиями выполнять произвольные действия с административными правами. Функция была доступна после входа, но не была должным образом ограничена по роли.

API6: Unrestricted Access to Sensitive Business Flows

Суть уязвимости. Она проявляется, когда API не ограничивает доступ к критическим бизнес-функциям (создание транзакций, изменение балансов, одобрение кредитов и т.п.) на основе ролей или прав пользователя. Подобные ситуации могут возникать в регистрационных и профильных эндпоинтах (куда можно добавить «лишние» поля) или в логике обработки управляющих операций. Например, корректировка статусов заявок без проверок роли.

Опасность атаки в том, что она не использует технические уязвимости, а эксплуатирует слабости в бизнес-логике.

Примеры атак. Несколько лет назад во время предпродажи билетов на платформе Ticketmaster злоумышленники автоматизировали пользовательский сценарий через API (прохождение очереди, поиск доступных мест и их резервирование). Отсутствие ограничений позволило ботам массово резервировать билеты, не оплачивая их, блокируя доступ реальным покупателям. Инцидент привёл к срыву продаж, сбоям платформы и публичным разбирательствам в США.

На Bugcrowd в прошлом году описывался ещё один критический сценарий злоупотребления бизнес-логикой. Платформа возвращала UUID заявки на вход в организацию, а дальше всё шло по цепочке: пользователь мог вторым API-вызовом самостоятельно «одобрить» собственную заявку и даже получить права админа. Технического взлома как такового не требовалось — сработала ошибка в логике чувствительного бизнес-процесса.

API7: Server-Side Request Forgery (SSRF)

Суть уязвимости. С помощью SSRF (Server-Side Request Forgery) злоумышленник заставляет сервер делать запросы к внутренним ресурсам, которые должны быть недоступны извне. API принимает URL от пользователя, например, для скачивания аватарки или вебхука и делает запрос от своего имени. Атакующий подсовывает внутренние адреса и получает доступ к облачным метаданным, внутренним сервисам, базам данных.

Атака обходит периметровую защиту, так как запрос инициируется изнутри сети. Поэтому традиционные брандмауэры и сканеры не видят такие угрозы, считая трафик легитимным.

Примеры атак. Один из самых показательных кейсов — история Capital One: там SSRF-уязвимость позволяла атакующему обратиться к облачному сервису метаданных AWS от имени уязвимого компонента и получить учётки с избыточными правами. Это привело к масштабной утечке клиентских данных. Кейс часто цитируют как один из самых наглядных примеров того, как SSRF в API и облачных сценариях выходит далеко за пределы «простого запроса по URL».

API8: Security Misconfiguration

Суть уязвимости. Из-за незащищённых дефолтных настроек, открытых функций или ошибок окружения, система становится уязвимой. Подобные бомбы замедленного действия нередко скрыты в серверах, СУБД или облачных сервисах. Например, продакшен-логи с debug-режимом, публичная документация Swagger/Redoc, CORS с Access-Control-Allow-Origin и т.п.

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

Примеры атак. Злоумышленники массово сканировали интернет на предмет открытых Docker API, которые торчали без авторизации. Через такие интерфейсы они деплоили вредоносные контейнеры, включали майнеры и начинали собирать ботнет. По сути, одна ошибка в API-интерфейсе превратилась в полноценный вектор компрометации.

API9: Improper Inventory Management

Суть уязвимости. Мы не можем защитить то, о чём не знаем. Как следствие, забытые эндпоинты становятся «вратами» для хакеров: Zombie API, Shadow API, тестовые эндпоинты в продакшене. Их с «большой любовью» эксплуатируют злоумышленники.

Примеры атак. В 2025 году была раскрыта веб-скимминг кампания. Атакующие брали устаревший эндпоинт Stripe /v1/sources и прогоняли через него украденные карты, проверяя их перед выводом на свои серверы. Атака затронула как минимум 49 интернет-магазинов. Смысл кейса в том, что старый интерфейс продолжал жить рядом с новыми API и фактически стал «забытым» активом.

API10: Unsafe Consumption of APIs

Суть уязвимости. Уязвимость эксплуатирует концепцию безоговорочного доверия к данным внешних API. А если твоё API интегрируется со сторонними сервисами, то автоматически мы наследуем их уязвимости. В итоге злоумышленники могут внедрить вредоносную нагрузку через цепочку интеграций, чтобы украсть данные.

Примеры атак. Уязвимость CVE-2021-41248 в GraphiQL: клиентский инструмент небезопасно обрабатывал ответы schema introspection и мог выполнить внедрённый JavaScript-код. По сути, проблема возникала не из-за «плохого» пользовательского ввода, а из-за доверия к данным, пришедшим от внешнего GraphQL-эндпоинта.

Новые векторы угроз

По мере развития технологий классические угрозы API из OWASP Top 10 дополняются новыми векторами атак, которые требуют особого внимания.

Атаки на цепочку поставок. Многие организации до конца даже не осознают, какие именно зависимости хранят их API. Вредоносные зависимости в пакетах (npm, PyPI и другие) могут компрометировать всю инфраструктуру.

Риски ИИ-интеграции. По данным Postman, 89% разработчиков используют генеративный ИИ, но только 24% проектируют API специально под взаимодействие с ИИ-агентами. Выходит, что большинство интерфейсов по умолчанию уязвимы перед атаками, специфичными для ИИ-сред. Типичные примеры: prompt injection, отравление датасетов или утечки через контекст, когда конфиденциальная информация может попасть в обучающие данные.

Проблемы версионности. В 2025 году 82% организаций так или иначе внедрили подход API-First. Доля тех, кто работает строго по этой модели, за год подскочила с 12% до 25% (в сравнении с 2024 годом).

Обратная сторона этого процесса — резкий рост количества версий, которые нужно поддерживать. На практике это выглядит так: несколько релизов API существуют параллельно, а старые эндпойнты, даже с закрытыми уязвимостями, остаются доступными «для совместимости». Этим и пользуются атакующие, целенаправленно выискивая и «дёргая» именно устаревшие реализации API .

Нарушения приватности. API часто логируют всё подряд, включая персданные. Если логи утекут, это чревато штрафами регуляторов и юридическими рисками.

Четыре ключевых подхода к защите API

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

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

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

Следом идёт регулярная проверка доступности, производительности, а также выявление аномалий в реальном времени. Причём простым сбором метрик тут уже не обойтись. Нужно анализировать поведение. Современные платформы на базе ML строят baseline для каждого интерфейса и пользователя. Как только ломается привычная последовательность операций, скачет частота запросов или доступ происходит в необычное время — система сразу генерит алерт.

Следующий элемент защиты — централизованная точка аутентификации, авторизации и управления трафиком (API Gateway). Шлюз централизует авторизацию, контролирует лимиты и маршрутизирует запросы, но считать его панацеей нельзя. Это лишь один слой, который обязан работать в связке с остальными компонентами.

И завершающий, но отнюдь не второстепенный штрих в наборе инструментов для защиты API — WAAP (Web Application and API Protection). В отличие от классического WAF, современные WAAP-решения объединяют функции WAF, API Gateway, bot management и DDoS protection, обеспечивая комплексную защиту.

Ключевое преимущество WAAP состоит в том, что мы получаем детальную телеметрию каждого вызова API с контекстом пользователя, приложения и сессии.

Для эффективного функционирования критически важно интегрировать с SIEM/SOAR все защитные компоненты, о которых я сказал выше. Это даёт ряд преимуществ:

• единую точку видимости всех API-взаимодействий;

• быстрое обнаружение аномалий и атак;

• автоматизированное расследование инцидентов;

• снижение нагрузки на SOC-аналитиков.

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