Простые шаги к защите API. Рекомендации для разработчиков и ИБ-специалистов
Изображение: recraft
1. Статистика по атакам на API. Актуальность темы
Продолжающаяся цифровая трансформация и взрывной рост использования искусственного интеллекта (ИИ) закрепили лидирующую роль API в бизнес-процессах крупных организаций.
Как следствие, растет и количество инцидентов, связанных с утечками через API. В 2025 году компания Akamai опубликовала результаты опроса, проведенного среди 800+ сотрудников компаний Азиатско-Тихоокеанского региона. Эти результаты показали, что организации регулярно сталкиваются с инцидентами, связанными с безопасностью API, а средний ущерб за последние 12 месяцев варьируется от 300 до 800 тысяч долларов. Рассмотрим пару наиболее значимых утечек из API сервисов, произошедших в 2024 году.
DELL — 49 млн записей
Хакер обнаружил возможность регистрации на партнерском портале DELL, которая не требует дополнительно верификации – достаточно лишь заполнить форму заявки. Далее, использовав вновь созданную учетную запись, злоумышленник с помощью скрипта собирал через API информацию о клиентах по семизначному сервисному тэгу. При этом скрипт работал в течение трех недель без каких-либо блокировок, генерируя до 5000 запросов в минуту.
Twilio – 33 млн записей
В конце июня 2024 г. хакеры украли 33 млн записей, связанных с двухфакторным приложением аутентификации Authy от Twilio. Утечка информации включала телефонные номера, идентификаторы учетных записей и некоторые другие не персональные данные, связанные с пользователями Authy. Позднее Twilio подтвердила, что злоумышленники смогли идентифицировать данные, связанные с учетными записями Authy, включая телефонные номера, из-за отсутствия аутентификации на одном из эндпойднтов в API компании.
Отдельно стоит отметить рост числа уязвимостей, связанных с использованием API в коммерческом и открытом программном обеспечении (ПО):
| Год | Количество уязвимостей в API (% от всех уязвимостей) |
| CVE-2024 | 1284 (3,2 %) |
| CVE-2023 | 874 (3,02%) |
| CVE-2022 | 634 (2,53%) |
Некоторые из этих уязвимостей широко используются в атаках на крупные организации. Например, в мае 2025 года стало известно от том, что хакеры эксплуатируют известную уязвимость в API популярного MDM решения Ivanti Endpoint Manager Mobile (CVE-2025-4428). Целями атаки являлись организации по всему миру. Среди пострадавших:
- Учреждения национальной службы здравоохранения Великобритании
- Производитель медицинских устройств в США
- Немецкий федеральный научно-исследовательский институт
- Ирландская аэрокосмическая лизинговая фирма
- Японский поставщик автомобильной электроники и трансмиссий
- Южнокорейский банк
Таким образом, если вы используете API, то необходимо учитывать релевантные угрозы и применять защитные меры.
2. OWASP API TOP 10
Список OWASP API Security Top 10 представляет собой перечень актуальных и наиболее опасных уязвимостей в API, собранный командой разработчиков и консультантов по информационной безопасности OWASP (Open Web Application Security Project). Данный список появился впервые в 2019 и спустя 4 года получил обновление, в котором половина прежних уязвимостей ушла из топа на фоне более серьезных проблем.
Почему новые уязвимости продолжают появляться, какие тенденции есть прямо сейчас и на что следует обращать внимание при проектировании и разработке API?
API продолжает стремительно набирать популярность и развиваться технологически, а атаки злоумышленников становятся все изощреннее, поскольку появляются новые инструменты для проведения атак. К примеру, использование атак типа DDoS и brut-force на API, а также автоматизация действий злоумышленников путем использования ботов для перебора параметров API приводят к реализации уязвимости Unrestricted Resource Consumption, когда злоумышленник может перегрузить систему, вызывая один или несколько API-методов, использующих ограниченные ресурсы сервера: БД, процессор, память, сеть. В результате происходит остановка сервиса и замедляется или останавливается работа системы целиком, что приводит к значительным финансовым и репутационным потерям. Для защиты от такого сценария необходимо вводить ограничения количество запросов, а также объем данным, принимаемых на вход со стороны API. Полезно, когда лимиты могут учитывать статистику на каждого клиента, а также сохранять статистику (относительные лимиты). В качестве реакции на превышение лимитов может быть блокировка по IP-адресу, токену или требование решить капчу (CAPTCHA).
Другой тенденцией является повсеместное распространение REST API и GraphQL. Вместе с их популярностью среди разработчиков растет риск того, что пользователь сможет изменить любые поля, даже к которым не должен иметь доступа. Дело в том, что в REST API часто используются PATCH-запросы, которые позволяют частично обновлять объект. Если сервер принимает все поля без проверки прав пользователя и легитимности предоставления ему доступа к полям — возникает уязвимость Broken Object Property Level Authorization, ставшая частным случаем ранее известной уязвимости BOLA. Только если в BOLA речь идёт о целом объекте, в данной ситуации проблема возникает на уровне отдельных полей. В случае с GraphQL повышается риск манипуляции с данными, к которым у пользователя не должно быть доступа, поскольку GraphQL позволяет запрашивать только нужные поля. Для минимизации риска в такой ситуации следует осуществлять проверку доступа на уровне полей, отказаться от автоматического обновления всех полей и проводить валидацию входных данных, проверяя все параметры каждого поля.
Третьей тенденцией является популяризация API-first концепции, которую все большее число компаний принимает за основу своей архитектуры. Это приводит к тому, что API начинают отвечать за большую часть процессов и все чаще API становятся зависимы от внешних источников данных, которые не проходят предварительной проверки, что в свою очередь может привести к компрометации системы и утечке конфиденциальной информации. Такая уязвимость относится к категории Software and Data Integrity Failures, и не теряет своей актуальности как в части классических веб-уязвимостей, так и уязвимостей в API. Мерами защиты в данном случае могут стать валидация и санитизация всех входных данных, использование mapping-а и фильтрации с целью изоляции вызовов внешних систем, обеспечение проверки источника на подлинность, а также принятие белого списка допустимых полей.
Ниже приведен полный список ТОП-10 OWASP API уязвимостей с кратким описанием проблемы и возможным решением.
3. Популярные инструменты из мира Open Source и их назначение
Как правило, коммерческие решения предлагают полный комплекс мер по защите API. Но вы также можете использовать инструменты с открытым кодом, чтобы закрыть хотя бы наиболее критичные проблемы. Скорее всего, это потребует значительно больших усилий на этапах внедрения и сопровождения, зато даст большую гибкость в настройках параметров защиты, а также позволит команде обрести необходимую экспертизу. Рассмотрим наиболее популярные инструменты по категориям:
a. Поиск эндпойнотов и точек входа в исходных кодах позволяет определить поверхность атаки, а также более комплексно подойти к тестированию на уязвимости:
b. Уязвимые API для обучения и тестирования помогут команде быстро понять типовые угрозы, способы их эксплуатации и методы защиты:
crAPI
VAmPI
с. Автоматическое построение Open API спецификации по запросам и ответам помогает сделать инвентаризацию, когда отсутствует какое-либо описание.:
Такое описание также можно использовать в других инструментах
d. Анализ Open API спецификации дает возможность выявить проблемы с реализацией на этапах разработки и тестирования:
cherrybomb
e. Сканнеры уязвимостей в API как правило требуют наличия спецификации Open API, но также могут работать в ручном режиме, когда вы сами отправляется запросы:
f. Фаззинг-тестирование с помощью передачи на вход API неправильных данных позволяет выявить уязвимости, которые пропустили сканнеры:
cats
Это далеко неполный перечень инструментов с открытым кодом, большое количество материалов и утилит можно найти в этом репозитории:
4. Необходимость построения цикла безопасности API. Резюме
Статистика, приводимая лидерами рынка в части безопасности API, показывает: среднестатистическая утечка через API компрометирует в 10 раз больший объем данных, чем любая другая утечка. Принимая во внимание растущую популярность API, а также выше рассмотренные тенденции и риски, необходимость комплексной защиты API становится очевидной.
Полный цикл безопасности API подразумевает системный подход к защите API на всех этапах их жизненного цикла:
проектирование → разработка → тестирование → деплой → эксплуатация → вывод из эксплуатации.
Согласно отчету Gartner, при рассмотрении процесса защиты API особое внимание стоит уделить этапам тестирования, деплоя, и эксплуатации: предлагаем рассмотреть основные тезисы, лежащие в основе построения безопасности API на этих этапах.
Нужны новые подходы к мониторингу и обнаружению угроз API.
Традиционных WAF и API Gateway становится недостаточно для обнаружения сложных атак через API. Традиционные WAF трансформируются в WAAP (Web Application and API Protection), где защита API выделяется в отдельный, как правило, облачный модуль. Также формируется направление по фокусной защите API — API Protection Platforms, к представителям которого можно отнести продукты Salt Security, Akamai API Security и Q-APISec.
Безопасность API складывается из 3 основных факторов:
- Обнаружение (инвентаризация) API. Необходима идентификация всех API, используемых в организации. Основная задача — своевременно обнаружить спящие (“Zombie-API”) и теневые API, о которых отделу ИБ зачастую ничего не известно.
- Управление состоянием безопасности API. Необходимо проверка конфигураций API на предмет наличия уязвимостей на уровне логики или из списка OWASP API.
- Runtime защита API. Необходим анализ запросов и ответов API в режиме реального времени на соответствие политикам безопасности и принятым в организации Swagger/OpenAPI-схемам.
Безопасность API должна быть синхронизирована с DevSecOps, что обеспечит автоматическую проверку на каждом этапе CI/CD.
Если подвести черту под всем вышесказанным, выстраивание полного цикла безопасности API — уже не дополнительная опция, а первостепенная необходимость, и надо стремиться к интеграции безопасности в каждый этап жизненного цикла API.
Павел Нагин, Руководитель по развитию продуктов SQUAD
Мария Фомина, Заместитель директора по развитию бизнеса ITD Group
