API Security: защита современных веб-приложений

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

Проблема усугубляется тем, что традиционные средства защиты, такие как WAF, SAST- и DAST-сканеры, не покрывают всех рисков, характерных именно для API. Требуется отдельная практика, встроенная в жизненный цикл разработки. Разберем, как построить эффективную защиту API на реальных проектах.

Почему безопасность API требует отдельного подхода

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

OWASP выделяет 10 основных рисков безопасности API (API Security Top 10). Основные из них:

• API1:2023 — Некорректная авторизация на уровне объекта (BOLA/IDOR). Это самая частая и опасная уязвимость. Она возникает, когда API принимает идентификатор объекта (например, user_id) и не проверяет, имеет ли текущий пользователь право на доступ к нему. Злоумышленник просто меняет ID в запросе и получает чужие данные. На практике эта проблема решается использованием непредсказуемых идентификаторов (UUID) и, главное, обязательной проверкой прав на уровне кода для каждого эндпоинта (конечной точки веб-сервиса).
• API2:2023 — Некорректная аутентификация. Слабые механизмы проверки подлинности, утечки токенов, неправильная настройка OAuth могут привести к компрометации учетных записей. На проектах можно столкнуться с тем, что разработчики хранят API-ключи прямо в клиентском JavaScript-коде. Конкретные меры защиты зависят от приложения. Например, можно использовать короткоживущие токены (JWT с коротким TTL), механизм ротации токенов обновления (Refresh Token Rotation) и внедрение многофакторной аутентификации.
• API3:2023 — Некорректная авторизация на уровне свойств объекта. Это объединение проблем «массового присвоения» (mass assignment) и избыточного раскрытия данных. Например, когда API возвращает пользователю его данные вместе с внутренним полем isAdmin и, в свою очередь, принимает от клиента это поле и позволяет его изменить. Для защиты используются белые списки разрешенных полей со строгим определением объектов передачи данных (DTO, Data Transfer Objects).
• API4:2023 — Неограниченное потребление ресурсов. Отсутствие лимитов на количество запросов, размер полезной нагрузки и сложность запросов может привести к DoS-атакам и неожиданным счетам за облачные ресурсы. Требуется настройка ограничения скорости обработки запросов (Rate Limiting) на уровне API Gateway, а также на уровне отдельных эндпоинтов.
• API5:2023 — Некорректная авторизация на уровне функции (BFLA). Эта уязвимость возникает, когда пользователь с одним уровнем прав может выполнять функции, предназначенные для других ролей. Например, обычный клиент системы вызывает административный эндпоинт /api/admin/users. Для защиты необходимо строго разделять роли и проверять права на уровне каждого метода. На реальных проектах часто используют промежуточное ПО (Middleware), которое перед вызовом любого эндпоинта проверяет наличие у пользователя конкретного разрешения (permission), привязанного к этому эндпоинту. Это позволяет избежать ситуаций, когда разработчик забыл проставить в коде аннотацию с необходимой ролью.

API Security как процесс: инвентаризация, тестирование, защита, мониторинг

Мы выделили несколько этапов, которые позволяют системно подойти к безопасности API. Современный подход предполагает защиту на всех этапах их жизненного цикла. Этот принцип лежит в основе концепции «Shift Everywhere». Разберем, как выстроить эффективную защиту API.

1. Получение и управление API-спецификацией

Это отправная точка. Без актуальной спецификации невозможно настроить ни эффективное тестирование, ни защиту на уровне WAF. На практике часто бывает, что спецификация устарела или отсутствует.

Как можно подойти к решению:

• Генерация спецификации из кода. Использование утилит вроде OpenAPI Generator или OWASP Noir позволяет автоматически создавать спецификации на основе исходного кода.
• Извлечение из трафика. Если доступ к коду отсутствует, можно проанализировать сетевой трафик с помощью инструментов mitmproxy, Proxify или APIClarity. Это также поможет выявить «теневые» эндпоинты, о которых разработчики могли забыть.
• Дообогащение. После получения базовой спецификации, для поиска скрытых/ненайденных эндпоинтов можно дополнительно использовать инструменты вроде ffuf или Kiterunner, которые перебирают возможные пути.
• А для валидации полученной спецификации на соответствие стандартам подойдут инструменты Spectral или vacuum.

В нашей практике мы периодически находим «забытые» эндпоинты, которые не были задокументированы, но при этом были доступны извне. Некоторые из них содержат критические уязвимости и позволяют получать доступ к конфиденциальным данным без соответствующей роли. Также встречаются оставленные старые версии API под новыми версиями в пути. Например, /api/v0/ может быть доступна при текущей /api/v1/.

2. Интеграция проверок в CI/CD

Тестирование API не должно быть разовым актом. Оно должно запускаться автоматически при каждом изменении кода. Здесь важно использовать подход добавления проверок безопасности в CI/CD.

Что дополнительно к классической безопасности внедряем в пайплайны:

• Статический анализ спецификации. Проверяем сам файл спецификации на наличие слабых мест в дизайне (отсутствие требований к аутентификации, неправильные схемы ответов) с помощью линтеров, таких как Spectral.
• Динамическое тестирование (DAST) и фаззинг. Здесь инструменты используют спецификацию для генерации запросов. Важно проверять не только наличие уязвимостей, но и устойчивость к невалидным данным.
  • Open-source фаззеры: RESTler (от Microsoft) и Schemathesis могут генерировать и мутировать данные.
  • DAST-сканеры: российские решения PT BlackBox, SolidPoint, Solar appScreener и open-source инструмент ZAP имеют модули для тестирования API.

Также важна дополнительная настройка аутентификации и авторизации, поскольку не все инструменты умеют поддерживать сессии и цепочки запросов конкретного приложения. Например, при тестировании API сначала нужно пройти авторизацию, а уже затем выполнять действия с полученным токеном. Здесь может понадобиться ручная доработка скриптов тестирования или использование инструментов, позволяющих настраивать контекст выполнения запросов.

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

3. Выход в продакшен: защита в реальном времени

Когда API работает, безопасность не заканчивается. Наоборот, начинается самый ответственный этап – защита живого трафика.

Инструменты и практики:

• API Gateway. Это промежуточный слой между клиентом и серверными сервисами, через который проходят запросы к API. С его помощью можно настроить маршрутизацию запросов, агрегацию данных, проверку аутентификации на входе, управление версиями API, валидацию схем и ограничения по скорости обработки запросов.
• Специализированный API Firewall. Это межсетевой экран, который проверяет и фильтрует запросы к API. В отличие от традиционных WAF (Web Application Firewall), он работает на основе позитивной модели безопасности. Это значит, что разрешено только то, что явно описано в спецификации. Всё остальное блокируется. Такой подход эффективнее защищает от атак на API. Среди российских решений можно выделить Вебмониторэкс ПроAPI.
• Обнаружение аномалий и новых эндпоинтов. Анализ живого трафика позволяет:
  • выявлять новые, недокументированные эндпоинты, которые появились в коде, но не прошли полноценные проверки ИБ;
  • находить «зомби-API» — устаревшие версии, которые уже не используются, но всё еще доступны;
  • отслеживать утечки данных в ответах. Это может быть как конфиденциальная информация, так и случайная отправка API-ключей или паролей.

Внедрять подобные инструменты обычно начинают в режиме «audit only» (только логировать нарушения, но не блокировать). Это хорошо помогает донастроить инструмент. Однако важно не находиться в подобном формате годами и вовремя перейти на блокирующий режим.

Уроки

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

Начните с самых критичных эндпоинтов, которые работают с финансами, персональными данными и аутентификацией. Здесь необходим максимальный контроль. Для публичных и read-only методов подходят менее строгие проверки. Также стоит измерять влияние на пользовательский опыт, потому что безопасность, которая мешает бизнесу, не будет эффективной.

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

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

Главный вывод

API Security – это не просто набор инструментов, а культура и процесс. Он требует взаимодействия разработчиков, тестировщиков и специалистов по безопасности на всех этапах, от проектирования до мониторинга в продакшене.

Резюмируя шаги:

• Начните с инвентаризации.
• Интегрируйте проверки в CI/CD.
• Не забывайте про ручной контроль.
• Защищайте живой трафик.
• Постоянно мониторьте инциденты.

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

Автор:
Ковтун Мария, руководитель направления динамического анализа безопасности приложений Свордфиш Секьюрити.