API в информационной безопасности: угрозы, уязвимости и способы защиты

API — Application Programming Interface, или программный интерфейс приложения. Он определяет правила, по которым одна система обращается к другой.

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

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

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

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

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

Методические ориентиры

В качестве основного ориентира для классификации рисков в статье используется OWASP API Security Top 10 2023 . Документ включает десять категорий: нарушения авторизации на уровне объектов, ошибки аутентификации, нарушения авторизации на уровне свойств объектов, неконтролируемое потребление ресурсов, нарушения авторизации на уровне функций, неограниченный доступ к чувствительным бизнес-процессам, SSRF, ошибки конфигурации, ненадлежащее управление инвентаризацией и небезопасное использование сторонних API.

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

Для рекомендаций по OAuth 2.0 используется RFC 9700 , опубликованный как Best Current Practice в январе 2025 года. Для JWT применяется RFC 8725 , который описывает базовые требования к проверке алгоритмов, криптографических операций, издателя, получателя и других параметров токена.

Что такое API и как он работает

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

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

API не обязательно доступен из интернета. Он может работать только внутри корпоративной сети, однако внутреннее размещение само по себе не гарантирует безопасность.

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

Основные компоненты API

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

Обмен часто происходит по протоколу HTTP. Для выполнения действий применяют стандартные методы:

• GET — получить данные;
• POST — создать объект или запустить операцию;
• PUT — заменить объект;
• PATCH — изменить отдельные поля;
• DELETE — удалить объект.

Запрос может содержать заголовки, параметры и тело. В заголовках часто передают токен доступа и указывают формат данных. Параметры помогают определить объект или условия выборки.

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

Ответ сервера включает код состояния и данные. Он также может содержать сообщение об ошибке, но такое сообщение не должно раскрывать внутреннее устройство системы.

Основные типы API

REST — Representational State Transfer — архитектурный стиль, широко используемый при создании веб-API. Он предполагает работу с ресурсами через адреса и стандартные методы HTTP.

SOAP — Simple Object Access Protocol — протокол обмена структурированными сообщениями. Он часто применяется в корпоративных системах.

GraphQL позволяет клиенту указывать, какие поля нужны в ответе. Это может сократить объем передаваемых данных, но требует дополнительного контроля состава и сложности запросов.

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

По модели доступа API можно разделить на несколько групп:

• внутренние — для систем одной организации;
• партнерские — для согласованного круга компаний;
• публичные — для внешних разработчиков и клиентов.

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

Пример взаимодействия через API

Пользователь входит в мобильное приложение. Клиент отправляет учетные данные серверу аутентификации.

После проверки сервер возвращает токен. Приложение добавляет его к следующим запросам.

Когда пользователь открывает профиль, приложение обращается к соответствующему эндпоинту. Сервер проверяет токен и права доступа, а затем возвращает только разрешенные поля.

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

В таком случае авторизованный пользователь сможет получить чужие данные, изменив идентификатор в запросе.

Какую роль API играет в информационной безопасности

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

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

SIEM — Security Information and Event Management — собирает и сопоставляет события безопасности. Для интеграции с источниками SIEM-системы часто используют API.

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

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

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

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

Почему API представляет интерес для злоумышленников

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

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

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

Документация также бывает неполной. Иногда реальный набор функций шире официального описания. Такие неучтенные интерфейсы часто относят к Shadow API.

Уязвимость API может затронуть сразу несколько каналов. Один интерфейс нередко обслуживает сайт, мобильное приложение и партнерскую интеграцию.

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

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

Основные угрозы и уязвимости API

Уязвимости API редко сводятся к одной технической ошибке. Часто проблема возникает на стыке архитектуры, программного кода и бизнес-правил.

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

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

Ошибки аутентификации

Аутентификация подтверждает личность пользователя или системы. Ошибка на этом этапе позволяет злоумышленнику выдать себя за доверенного субъекта.

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

MFA — Multi-Factor Authentication — снижает риск захвата учетной записи, но не защищает уже украденный токен.

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

Сервер должен проверять срок действия, подпись, издателя, получателя и назначение токена. Набор проверок зависит от формата токена и используемого протокола. Для JWT недостаточно проверить только подпись: необходимо также разрешать только предусмотренные алгоритмы и проверять значимые claims.

Нарушение авторизации на уровне объектов

Успешная аутентификация не означает, что пользователь может обращаться ко всем объектам.

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

Проверку необходимо выполнять при каждом обращении к объекту независимо от типа идентификатора. Использование UUID вместо последовательного числа усложняет угадывание, но не заменяет авторизацию. OWASP относит такие ошибки к Broken Object Level Authorization .

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

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

Скрытая кнопка в интерфейсе не ограничивает доступ к серверной функции. Сервер должен проверять полномочия для каждого действия.

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

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

API может разрешать пользователю читать или изменять объект, но не все его поля.

Например, клиент имеет право изменить отображаемое имя, но не роль, владельца или служебный статус. Если сервер автоматически применяет все поля из запроса, пользователь может изменить защищенное свойство.

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

Фильтрация на стороне клиента не считается защитой: пользователь может изучить исходный ответ самостоятельно. Сервер должен отдельно определять разрешенные входные и выходные поля для каждого сценария.

В OWASP API Security Top 10 2023 такие ошибки объединены в категорию Broken Object Property Level Authorization .

Инъекции

Инъекция возникает, когда входные данные попадают в команду или запрос без безопасной обработки.

К этой группе относятся SQL-инъекции, командные инъекции и инъекции в запросы к NoSQL-системам. Последствия зависят от полномочий серверного процесса.

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

Для защиты применяют параметризованные запросы и строгую проверку входных данных. Черные списки отдельных символов не обеспечивают надежной защиты.

Система должна принимать только ожидаемые типы, форматы и диапазоны значений. Остальные данные следует отклонять.

Инъекции не выделены в отдельную категорию OWASP API Security Top 10 2023, но это не означает, что они неприменимы к API. Классификация OWASP API Security Top 10 не является исчерпывающим перечнем всех возможных уязвимостей.

Неконтролируемое потребление ресурсов

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

Недостаточно ограничивать только число запросов в секунду. Необходимо учитывать:

• размер тела запроса;
• размер загружаемого файла;
• число элементов в коллекции;
• глубину вложенности;
• сложность GraphQL-запросов;
• длительность выполнения;
• число параллельных операций;
• обращения к платным внешним сервисам.

Один ресурсоемкий запрос может создать значительную нагрузку даже при низкой частоте обращений. OWASP относит этот риск к категории Unrestricted Resource Consumption .

Лимиты можно задавать по пользователю, токену, приложению, операции и сетевому адресу. IP-адрес нельзя считать надежным идентификатором: его следует использовать только как один из сигналов.

Неограниченный доступ к чувствительным бизнес-процессам

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

Например, пользователь может:

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

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

OWASP выделяет такие сценарии в категорию Unrestricted Access to Sensitive Business Flows . Конкретный риск зависит от отрасли и бизнес-модели системы.

SSRF

SSRF — Server-Side Request Forgery — возникает, когда сервер обращается по адресу, полученному от клиента, без достаточных ограничений.

Например, API может загружать изображение по указанному URL, проверять webhook или получать документ из внешней системы. Злоумышленник пытается заставить сервер обратиться:

• к внутреннему сервису;
• к интерфейсу управления;
• к метаданным облачной среды;
• к адресу, недоступному извне;
• к ресурсу через цепочку перенаправлений.

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

Небезопасная конфигурация

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

Подробные сообщения об ошибках способны раскрыть версии компонентов и структуру базы данных. Эти сведения упрощают подготовку атаки.

CORS — Cross-Origin Resource Sharing — определяет правила доступа к ресурсам из других источников. Слишком широкая политика может повысить риск злоупотреблений, но последствия зависят от способа аутентификации и использования API клиентами.

HTTP-соединения с API следует защищать с помощью HTTPS. При этом необходимо правильно настроить сертификаты, поддерживаемые версии TLS и параметры шифрования.

К небезопасной конфигурации также относятся:

• ненужные HTTP-методы;
• административные интерфейсы в общем контуре;
• стандартные учетные данные;
• отсутствие обновлений;
• избыточные сетевые разрешения;
• неправильная обработка заголовков прокси;
• открытые спецификации и отладочные эндпоинты без обоснованной необходимости.

Shadow API и устаревшие версии

Shadow API — действующий интерфейс, который не включен в официальный реестр или не контролируется в рамках установленного процесса.

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

Устаревшие версии расширяют поверхность атаки, требуют отдельных обновлений и могут сохранять функции, уже закрытые в новой версии. OWASP относит неполную документацию, отсутствие плана вывода версий и устаревший реестр к Improper Inventory Management .

Для контроля необходим единый реестр. В нем следует указывать:

• владельца;
• назначение;
• версию;
• среду;
• способ публикации;
• обрабатываемые данные;
• используемую аутентификацию;
• зависимые и сторонние системы;
• плановую дату пересмотра или отключения.

Ограничения автоматического обнаружения API

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

Средство обнаружения может пропустить:

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

Поэтому инвентаризацию следует строить на нескольких источниках:

• конфигурациях API Gateway, WAF, балансировщиков и reverse proxy;
• журналах приложений и сетевом трафике;
• спецификациях OpenAPI и репозиториях исходного кода;
• реестрах облачных ресурсов и контейнерных платформ;
• DNS, CMDB и каталогах сервисов;
• настройках service mesh;
• данных от владельцев систем.

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

Небезопасное использование сторонних API

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

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

Необходимо:

• проверять формат и допустимые значения;
• ограничивать размер ответа;
• задавать тайм-ауты;
• контролировать перенаправления;
• проверять сертификаты;
• ограничивать сетевые назначения;
• учитывать отказ или компрометацию поставщика;
• не передавать внешнему сервису лишние данные.

OWASP включает этот класс риска в категорию Unsafe Consumption of APIs .

Примеры атак на API

Представим сервис управления корпоративными заявками. Пользователь открывает свою заявку по адресу с числовым идентификатором.

Он меняет номер и получает документ другого отдела. Сервер проверил токен, но не убедился, что объект принадлежит этому пользователю или доступен ему по роли.

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

Еще один пример связан с восстановлением пароля. Интерфейс ограничивает попытки входа, но не ограничивает ввод кодов подтверждения.

Злоумышленник автоматизирует перебор и при недостаточно стойком механизме подтверждения получает доступ к учетной записи.

Опасны и административные функции. Сервер может скрыть кнопку в обычном интерфейсе, но оставить эндпоинт доступным.

Пользователь вызывает функцию напрямую и изменяет свою роль. Причина — отсутствие серверной проверки прав.

Атаки возможны и без обхода контроля доступа. Например, API возвращает карточку клиента со служебными полями.

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

Все эти сценарии объединяет один принцип: клиентское приложение нельзя считать доверенной зоной.

Аутентификация и авторизация в API

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

Эти процессы связаны, но не заменяют друг друга. Корректный токен не дает автоматического доступа ко всем данным и функциям.

API-ключи

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

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

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

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

Токены

Access token предоставляет доступ к ресурсам в пределах назначенных полномочий. Refresh token позволяет получить новый access token без повторного прохождения полной процедуры входа.

Универсального безопасного срока действия токена нет. Его выбирают с учетом:

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

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

Refresh token требует усиленной защиты, поскольку с его помощью можно получать новые access tokens.

RFC 9700 требует для публичных OAuth-клиентов использовать ротацию refresh tokens или криптографическую привязку токена к экземпляру клиента. Документ также рекомендует прекращать действие refresh token после периода неактивности, но оставляет конкретный срок на усмотрение сервера авторизации с учетом политики клиента и чувствительности полномочий.

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

OAuth 2.0 и OpenID Connect

OAuth 2.0 используют для делегирования доступа. Он позволяет приложению получить ограниченные полномочия без передачи пароля пользователя этому приложению.

OpenID Connect добавляет механизм идентификации пользователя поверх OAuth 2.0.

Недостаточно убедиться, что токен правильно подписан. Необходимо проверить:

• допустимый алгоритм;
• издателя;
• получателя;
• срок действия;
• назначение токена;
• область доступа;
• соответствие токена конкретному API.

RFC 9700 рекомендует ограничивать полномочия access token минимально необходимыми ресурсами и действиями, а также по возможности ограничивать аудиторию конкретным сервером ресурсов.

Конкретные требования зависят от используемого потока OAuth, типа клиента и архитектуры системы.

Ролевая и атрибутная модели доступа

RBAC — Role-Based Access Control — назначает права через роли. Например, оператор может читать заявки, а руководитель — согласовывать их.

ABAC — Attribute-Based Access Control — учитывает атрибуты пользователя, объекта и контекста: например, подразделение, регион или время запроса.

RBAC обычно проще администрировать. ABAC позволяет точнее описывать правила, но требует более сложного управления политиками.

Обе модели должны соответствовать принципу минимальных привилегий. По умолчанию доступ следует запрещать.

Сравнение методов

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

Основные меры защиты API

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

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

Инвентаризация интерфейсов

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

Для каждого API рекомендуется указать:

• владельца;
• назначение;
• версию;
• среду размещения;
• точки публикации;
• доступные данные;
• методы аутентификации;
• критичные операции;
• внешние зависимости;
• дату следующей проверки;
• план вывода версии из эксплуатации.

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

Безопасная аутентификация

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

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

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

Централизованное управление упрощает отзыв доступа и снижает риск хранения секретов в исходном коде.

После увольнения сотрудника или отключения системы доступ следует закрывать без неоправданных задержек. По возможности этот процесс нужно автоматизировать.

Строгая авторизация

Каждый эндпоинт должен проверять доступ к функции, объекту и отдельным защищенным свойствам.

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

Следует применять принцип deny by default — запрет по умолчанию. Доступ предоставляется только после явной проверки.

Проверка входных и выходных данных

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

Необходимо ограничивать размер тела запроса, количество элементов, глубину вложенности и сложность обработки.

Выходные данные также требуют контроля. Ответ должен содержать только поля, необходимые конкретному клиенту или сценарию.

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

Шифрование

Внешние HTTP-соединения с API следует защищать с помощью HTTPS.

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

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

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

Ограничение запросов

Rate limiting ограничивает частоту запросов, а квоты — доступный объем операций за определенный период.

Универсальных значений лимитов нет. Их рассчитывают с учетом:

• нормальной нагрузки;
• стоимости операции;
• допустимого времени ответа;
• критичности функции;
• возможностей инфраструктуры;
• риска автоматизации;
• зависимости от внешних платных сервисов.

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

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

Журналирование и мониторинг

API должен фиксировать:

• попытки входа;
• отказы в доступе;
• изменения прав;
• административные действия;
• критичные бизнес-операции;
• превышение лимитов;
• ошибки проверки токенов;
• изменения конфигурации.

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

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

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

Инструменты защиты API и их ограничения

Инструменты решают разные задачи. Возможности конкретного продукта зависят от архитектуры, конфигурации и доступных интеграций.

API Gateway или WAF не должны быть единственным местом проверки прав. Если запрос достиг внутреннего сервиса другим маршрутом, защита не должна исчезать.

Автоматические сканеры помогают находить известные классы ошибок, но не подтверждают безопасность API целиком.

Тестирование безопасности API

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

Анализ документации и архитектуры

Сначала следует определить:

• участников обмена;
• доверенные зоны;
• точки публикации;
• способы аутентификации;
• места принятия решений о доступе;
• критичные данные;
• сторонние зависимости.

Затем выделяют критичные операции: например, платежи, изменение ролей, экспорт данных и управление конфигурацией.

Полезно заранее описать сценарии злоупотребления. Например, определить, что произойдет при повторной отправке запроса, изменении порядка операций или массовом обращении к функции.

Автоматизированное тестирование

Автоматизированные средства проверяют известные классы ошибок и могут сравнивать реальное поведение со спецификацией.

Спецификация OpenAPI описывает методы, параметры и схемы ответов. Ее можно использовать для контроля изменений, но соответствие спецификации само по себе не подтверждает безопасность реализации.

Автоматические проверки полезны для поиска инъекций, ошибок обработки данных и небезопасных настроек. Однако они ограниченно учитывают смысл бизнес-операций.

Ручное тестирование

Специалист проверяет:

• доступ между пользователями;
• доступ между ролями;
• права на отдельные объекты;
• изменение защищенных полей;
• массовые операции;
• экспорт данных;
• повторение запросов;
• нестандартный порядок действий;
• обход установленных лимитов.

Особого внимания требуют объекты с предсказуемыми идентификаторами. Однако непредсказуемый идентификатор не исключает необходимость проверки прав.

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

Тестирование в процессе разработки

Проверки следует встраивать в CI/CD — Continuous Integration and Continuous Delivery.

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

Отдельно необходимо контролировать изменения прав и схем ответов. Даже незаметное добавление поля может привести к раскрытию данных.

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

Периодичность тестирования

Универсального интервала для всех API нет.

Проверки проводят:

• перед первоначальной публикацией;
• после существенных изменений архитектуры;
• после изменения аутентификации или модели доступа;
• после добавления критичных операций;
• после инцидента;
• после выявления уязвимости в используемом компоненте;
• периодически в соответствии с критичностью и частотой изменений.

Автоматизированные проверки целесообразно запускать при каждом изменении, которое затрагивает API. Объем ручного тестирования определяют по риску.

Безопасность API на разных этапах жизненного цикла

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

1. Проектирование

На этом этапе определяют данные, роли и доверенные зоны, а также проводят моделирование угроз.

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

2. Разработка

Разработчики используют безопасные функции и строгие схемы данных. Секреты хранят вне исходного кода.

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

3. Тестирование

Команда проверяет код, конфигурацию и работающий интерфейс. Критичные функции дополнительно тестируют вручную.

Результаты следует оформлять как задачи на исправление. Для каждой найденной проблемы нужно назначить ответственного и определить порядок устранения.

4. Публикация

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

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

5. Эксплуатация

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

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

6. Вывод из эксплуатации

Недостаточно удалить ссылку из документации. Эндпоинт нужно отключить на сервере, шлюзе и других точках маршрутизации.

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

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

Типичные ошибки компаний

Частая ошибка — защита только пользовательского веб-интерфейса. При этом API остается доступным для прямых запросов.

Другая проблема — отсутствие полного списка интерфейсов. Нельзя управлять защитой API, о существовании которого команда не знает.

Опасны долгоживущие токены с широкими полномочиями и без механизмов отзыва. При утечке злоумышленник может сохранять доступ до окончания срока действия или продолжать обновлять его через скомпрометированный refresh token.

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

Еще одна ошибка — доверие данным клиента. Сервер принимает переданную роль, стоимость, статус или идентификатор владельца без независимой проверки.

Избыточные ответы могут привести к утечке даже без обхода аутентификации.

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

Секреты в исходном коде создают долгосрочный риск. Даже после удаления из текущей версии они могут сохраниться в истории репозитория.

Устаревшие версии иногда продолжают работать без должного контроля. Клиенты используют их и после выпуска нового интерфейса.

Еще одна ошибка — считать установку WAF или API Gateway завершенной защитой. Эти средства не заменяют серверную авторизацию, управление жизненным циклом и тестирование бизнес-логики.

Заключение

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

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

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

Защита API сочетает архитектурные меры, безопасную разработку, регулярное тестирование, мониторинг и управление секретами.

Главное условие — знать все действующие интерфейсы. У каждого API должны быть владелец, назначение, определенный срок поддержки и контролируемые зависимости.

Часто задаваемые вопросы

Чем безопасность API отличается от безопасности сайта?

Сайт ориентирован на взаимодействие с человеком через пользовательский интерфейс. API предназначен для автоматического обмена данными между системами.

Для API особенно важны серверная авторизация, ограничение потребления ресурсов и контроль машиночитаемых ответов. Защита только веб-страниц не устраняет эти риски.

Можно ли считать API безопасным при использовании HTTPS?

Нет. HTTPS защищает данные при передаче, но не проверяет бизнес-логику и права пользователя.

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

В чем разница между API-ключом и токеном?

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

Токен обычно содержит или представляет ограниченные полномочия пользователя либо клиента и может иметь заданный срок действия.

Конкретные свойства зависят от реализации: API-ключ также может иметь ограниченный срок, а токен — использоваться для машинной интеграции.

Какой срок действия токена считается безопасным?

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

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

Как часто нужно проводить тестирование API?

Автоматизированные проверки целесообразно выполнять при изменениях, затрагивающих API.

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

Что такое Shadow API?

Shadow API — действующий интерфейс, который не включен в официальный реестр или не контролируется в рамках установленного процесса.

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

Ни один отдельный метод обнаружения не гарантирует, что будут найдены все интерфейсы.