
Почти все приложения общаются друг с другом через API (Application Programming Interface), то есть через специальный программный интерфейс. Это набор правил и протоколов, который позволяет разным программам понимать друг друга и обмениваться нужными данными. Но, чтобы приложение могло использовать API (понимать, как именно и с кем общаться), ему нужна спецификация – структурированный документ, который определяет схему проектирования, создания и взаимодействия. Спецификация обеспечивает согласованность, совместимость и беспрепятственный обмен данными между различными приложениями и компонентами системы.
API удобен, но есть нюанс. Через него проходит большой объем данных, в том числе конфиденциальных. Естественно, такое «богатство» интересует киберпреступников. Они могут с помощью уязвимостей API обойти авторизацию в приложении, получить ценные данные компании или клиентов и т.п.
Для защиты программных интерфейсов может использоваться API Firewall, который работает, как обратный прокси со встроенным валидатором запросов и ответов на основе спецификации. Решение использует позитивную модель безопасности: разрешены запросы, соответствующие заранее определенной спецификации API, а все остальное – запрещено.
Но это теория, а как защита работает в жизни? В данном посте мы постарались описать кейсы использования API Firewall на примере нашего решения ПроAPI Защита.
Проверка запросов на наличие аутентификации
Основные уязвимости по классификации OWASP API TOP10 напрямую или косвенно связаны с авторизацией и проблемами контроля доступа. Например, небезопасная аутентификация, подделка запросов на стороне сервера (SSRF), нарушение авторизации на уровне функций (BFLA) и другие. Последствия таких атак очевидны: несанкционированный доступ к веб-приложению и его данным.
Чтобы API Firewall защитил от этой угрозы, для начала необходимо собрать структуру приложения, определив, какие эндпоинты имеют PII (персонально идентифицируемая информация, иными словами - персданные). Одни компании еще на этапе разработки аккуратно собирают и структурируют такую информацию. Другим же потребуется провести дополнительную инвентаризацию API. В итоге в спецификации необходимо отметить, что для эндпоинтов с PII необходима обязательная аутентификация. API Firewall будет использовать это правило.
Теперь при неавторизованном запросе к API в менеджере API Firewall мы будем видеть событие типа “Ошибка валидации” с разъяснением, что отсутствует токен или куки авторизации:

Запрос с неопределенными параметрами
Запросы, содержащие параметры, которые не были явно определены или ожидаемы в спецификации API, являются серьезной угрозой для стабильности, безопасности и корректности работы приложения. Например, неожиданные (не описанные в спецификации) параметры могут активировать обходные пути или изменить логику проверки прав доступа, что ведет к обходу авторизации/аутентификации. Или, если сервер обрабатывает неизвестные параметры для отладки или логирования, это может привести к раскрытию внутренней структуры данных, путей к файлам или другой чувствительной информации. Кроме того, обработка неожиданных параметров может быть ресурсоемкой для сервера задачей. Это приводит к избыточному использованию CPU (центрального процессора), памяти или дисковых операций. Массовые запросы с такими параметрами могут вызвать отказ в обслуживании (DoS/DDoS).
Настраиваем API Firewall, запустив на нем спецификацию. Например, в ней отсутствует описание параметров include_all_products и include_sensitive для эндпоинта /public_data (условно назовем его так).
Проверяем: выполняем запрос к эндпоинту /public_data с перечисленными выше параметрами. Если API Firewall работает в режиме мониторинга, он фиксирует несоответствие и оповещает об этом пользователя. Если в режиме блокировки, то, соответственно, блокирует такой запрос/ответ. В менеджере мы видим данное событие с типом “Неопределённые параметры” и пояснением, что они не определены в OpenAPI спецификации:

Выявление Shadow API
Shadow API — это недокументированный API, который существует в инфраструктуре организации без надлежащего разрешения или контроля. С точки зрения спецификации Shadow API — это эндпоинт, представленный в фактическом трафике (обнаруженный Структурой API) и не представленный в вашей спецификации.
Представим достаточно классическую ситуацию расхождения между спецификацией и реализацией: API Firewall ожидает, что сервер в ответ на определенный запрос вернет HTTP-код 200 (OK), но сервер вместо этого возвращает 201 (Created).
Что за коды
201 (Created) — должен возвращаться, когда сервер успешно создал новый ресурс (например, после POST /users).
200 (OK) — общий код успешного выполнения, но без явного указания, что ресурс был создан.
Расхождение в кодах ведет к некорректному срабатыванию политик ИБ. Защитные меры такие, как схемы валидации ответов, обнаружение утечек данных или маскирование чувствительных полей, могут быть настроены на ожидание конкретных кодов ответов. Если приходит неожиданный 2xx код, эти политики могут не сработать, что создает серьезные риски ИБ:
Утечки данных: чувствительная информация (номера карт, логины) может уйти без маскировки.
"Shadow API": в системе могут появиться скрытые, незадокументированные эндпоинты с уязвимостями.
Автоматические атаки: злоумышленники часто сканируют API на такие несоответствия, чтобы найти слабые места.
Если такое базовое расхождение в кодах ответов существует и не исправляется, это указывает на отсутствие строгих процессов управления изменениями API в компании.
В этом случае API Firewall выступает в качестве арбитра: если приложение пытается сгенерировать некорректный ответ, API Firewall это видит и блокирует его, пресекая некорректные сработки настроек ИБ. При валидации ответов в режиме "Мониторинг" будет получен ответ с кодом 201, при этом в консоли управления мы увидим событие с типом "Shadow API на ответ", поскольку в спецификации API Firewall указан другой ожидаемый код 200:

При валидации ответов в режиме "Блокировка" будет получен ответ с кодом 403 заблокировано с сообщением о неподдерживаемом статусе, поскольку API Firewall ожидает код ответа 200, а бэкенд возвращает 201:

Блокировка запросов со скомпрометированными токенами
Токен API — это ключ для доступа к сервису. Компрометация токена — когда этот ключ попадает в руки злоумышленнику. Чтобы пресечь попытки эксплуатации утекших API, запуск API Firewall производится с дополнительными переменными окружения. В данных переменных:
задается точка монтирования и указывается файл с утекшими токенами;
объявляется название заголовка, передающего токен аутентификации;
-e APIFW_DENYLIST_TOKENS_FILE='/opt/data/tokens-denylist.txt'
-e APIFW_DENYLIST_TOKENS_HEADER_NAME='Authorization'
-v "$PWD/tokens-denylist.txt:/opt/data/tokens-denylist.txt"
В нашем примере файл tokens-denylist.txt содержит два утекших токена:
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcmVzaCI6ZmFsc2UsImlhdCI6MTc0OTQ1Nzc1OCwianRpIjoiOWE2YzA2Y2QtODFhNi00ZGM4LWE4MmUtNDgxM2E2ZWRjMGJmIiwidHlwZSI6ImFjY2VzcyIsInN1YiI6InVzZXIxIiwibmJmIjoxNzQ5NDU3NzU4LCJjc3JmIjoiMmU2OTgwNWYtODU1YS00NTY0LWI0NTYtNzk0YjZmN2UzMzIyIiwiZXhwIjoxOTgzNDU3NzU4fQ.EZuNCB8w-A97Kp1xcOyAVsSw7jjmBSx7BQ1J3M8dXhE
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcmVzaCI6ZmFsc2UsImlhdCI6MTc0OTQ1Nzg2NSwianRpIjoiOWYzZmZkN2EtNTQ4OS00N2VlLWE5NDgtNDkzODZlOWNlZjcyIiwidHlwZSI6ImFjY2VzcyIsInN1YiI6InVzZXIxIiwibmJmIjoxNzQ5NDU3ODY1LCJjc3JmIjoiM2ExODhjNzktZTk0ZC00MTBjLWE3N2MtY2I2ZjcwMDE0YzQ5IiwiZXhwIjoxOTgzNDU3ODY1fQ.ZJkJJNnEeIA6e3MeX7JK0JBuhugdfU-vXY3R--PsyJ8
Выполняем запрос к защищаемому приложению с валидным токеном и получаем ответ с кодом 201 (Created):
$ curl -iX 'GET' \
'https://flask.****.ru:8443/api/header_route' \
-H 'accept: application/json' \
-H 'Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcmVzaCI6ZmFsc2UsImlhdCI6MTc0OTQ1NDcxOCwianRpIjoiNmFkNTQ0NDItOWM3Mi00YzhmLTg2ZjQtYmY1ZDc4OGY5YjM2IiwidHlwZSI6ImFjY2VzcyIsInN1YiI6InVzZXIxIiwibmJmIjoxNzQ5NDU0NzE4LCJjc3JmIjoiNGFmNTcxMTYtNDYzNC00MjJlLWFmY2YtMGE1YWMzYjVhNGQzIiwiZXhwIjoxOTgzNDU0NzE4fQ.AiNmLAXoKWqG220x28io25J1jcG3dYiMsgILOilhcDA' \
-H 'Custom-Header: 1'
HTTP/1.1 201 CREATED
Server: Angie/1.9.0
Date: Thu, 29 May 2025 12:42:40 GMT
Content-Type: application/json
Content-Length: 48
Connection: keep-alive
Access-Control-Allow-Origin: *
{"message":"Response for 1 (GET), user: user1"}
Выполняя поочередно запросы со скомпрометированными токенами мы будем получать ответ с кодом 403 (Forbidden):
$ curl -iX 'GET' \
'https://****.ru:8443/api/header_route' \
-H 'accept: application/json' \
-H 'Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcmVzaCI6ZmFsc2UsImlhdCI6MTc0OTQ1Nzc1OCwianRpIjoiOWE2YzA2Y2QtODFhNi00ZGM4LWE4MmUtNDgxM2E2ZWRjMGJmIiwidHlwZSI6ImFjY2VzcyIsInN1YiI6InVzZXIxIiwibmJmIjoxNzQ5NDU3NzU4LCJjc3JmIjoiMmU2OTgwNWYtODU1YS00NTY0LWI0NTYtNzk0YjZmN2UzMzIyIiwiZXhwIjoxOTgzNDU3NzU4fQ.EZuNCB8w-A97Kp1xcOyAVsSw7jjmBSx7BQ1J3M8dXhE' \
-H 'Custom-Header: 1'
HTTP/1.1 403 Forbidden
Server: Angie/1.9.0
Date: Thu, 29 May 2025 13:19:40 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 0
Connection: keep-alive
$ curl -iX 'GET' \
'https://****.ru:8443/api/header_route' \
-H 'accept: application/json' \
-H 'Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcmVzaCI6ZmFsc2UsImlhdCI6MTc0OTQ1Nzg2NSwianRpIjoiOWYzZmZkN2EtNTQ4OS00N2VlLWE5NDgtNDkzODZlOWNlZjcyIiwidHlwZSI6ImFjY2VzcyIsInN1YiI6InVzZXIxIiwibmJmIjoxNzQ5NDU3ODY1LCJjc3JmIjoiM2ExODhjNzktZTk0ZC00MTBjLWE3N2MtY2I2ZjcwMDE0YzQ5IiwiZXhwIjoxOTgzNDU3ODY1fQ.ZJkJJNnEeIA6e3MeX7JK0JBuhugdfU-vXY3R--PsyJ8' \
-H 'Custom-Header: 1'
HTTP/1.1 403 Forbidden
Server: Angie/1.9.0
Date: Thu, 29 May 2025 13:22:46 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 0
Connection: keep-alive
Вывод
API — это синапсы современных приложений. Они связывают разные системы. И если злоумышленнику удалось успешно использовать недостатки API, последствия могут быть гораздо серьезнее, чем после взлома веб-интерфейса. API Firewall же помогает веб-приложению не допустить ошибку, в том числе случайно передав в руки хакеров ценные данные о самом приложении или о его пользователях.