Безопасность API: уязвимости и защита

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

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

Почему безопасность API — отдельная тема

Веб-сайт показывает пользователю ровно то, что нарисовал интерфейс. API отдаёт всё, что умеет сервер, любому, кто может отправить HTTP-запрос: мобильному приложению, фронтенду, партнёрской системе — и злоумышленнику, который узнал адреса методов из того же мобильного приложения. Интерфейс может прятать кнопку «Удалить», но если сервер не проверяет роль, метод удаления доступен всем.

Три особенности, из-за которых API уязвимее обычных страниц:

• Логика вместо шаблонов. Классические сканеры хорошо ищут устаревшие библиотеки и типовые ошибки конфигурации, но не понимают, что пользователь №1 не должен видеть заказ пользователя №2. Такие ошибки находит только ручная проверка или тесты, написанные под бизнес-правила.
• Много клиентов — много версий. Старое мобильное приложение продолжает ходить в первую версию API, которую «давно не поддерживают», но не выключили. Защиту добавили во вторую версию, а старый метод остался открытым.
• Невидимость. Методы API не индексируются поисковиками и не видны в карте сайта, поэтому их часто забывают включить в пентест и мониторинг. Команда может просто не знать полного списка.

OWASP API Security Top 10 2023: десять типичных уязвимостей

OWASP (Open Worldwide Application Security Project) ведёт отдельный список рисков для API. Актуальная редакция — 2023 года. Это карта приоритетов: с чего начать проверку и о чём спросить разработчиков.

Три категории из первой пятёрки — API1, API3 и API5 — посвящены авторизации. В API ошибки доступа — центральный класс проблем, и именно их хуже всего видят автоматические инструменты.

Авторизация: главное, что нужно закрыть

Проверка владения объектом на каждом запросе

Правило одно: сервер не доверяет идентификатору из запроса. Если клиент просит заказ, счёт или документ, сервер сам проверяет, что этот объект принадлежит текущему пользователю или его организации. Проверка делается централизованно — в слое доступа к данным или в общей политике доступа, а не вручную в каждом контроллере, где её рано или поздно забудут. Непредсказуемые идентификаторы (UUID вместо порядковых номеров) усложняют перебор, но не заменяют проверку.

Только нужные поля — на чтение и на запись

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

Роли и функции: запрет по умолчанию

Административные методы проверяют роль на сервере, даже если «в приложении этой кнопки нет». Хорошая практика — политика «запрещено всё, что явно не разрешено», и автотесты, которые для каждого метода выполняют вызов от роли без прав и ожидают отказ.

Аутентификация, токены и ключи

• Стандарты вместо самописных схем. OAuth 2.0 и OpenID Connect для пользователей, отдельные учётные данные для взаимодействия между серверами.
• Короткие токены доступа — минуты или часы — и токены обновления с ротацией и отзывом при выходе и смене пароля.
• Проверка подписи и параметров JWT на сервере: алгоритм из заранее заданного списка, срок действия, издатель, аудитория. Неподписанные токены не принимаются.
• Никаких секретных ключей в мобильном приложении и фронтенде. Всё, что попало в клиент, можно извлечь. Секреты хранятся только на сервере, в хранилище секретов, с плановой ротацией.
• Защита входа и восстановления пароля: лимиты попыток, одинаковые ответы для существующих и несуществующих учётных записей, двухфакторная аутентификация для администраторов и партнёрских кабинетов.

Лимиты, бизнес-процессы и внешние сервисы

Отсутствие ограничений бьёт и по доступности, и по деньгам. Метод «отправить код по SMS» без лимита превращается в счёт от провайдера, метод «задать вопрос AI-ассистенту» — в счёт за обращения к модели. Что настроить:

1. Лимиты частоты на пользователя, ключ и IP-адрес — на шлюзе или в приложении.
2. Максимальный размер запроса, число элементов на страницу, глубину вложенности запросов для GraphQL.
3. Таймауты и месячные бюджеты на обращения к платным внешним сервисам.
4. Для чувствительных сценариев — регистрации, промокодов, бронирования, выплат — отдельные бизнес-лимиты и оповещения о необычных всплесках.

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

Инвентаризация, конфигурация и журналы

Нельзя защитить API, о котором не знаете. Минимальный порядок:

• Реестр API: все сервисы, версии, окружения, владельцы и то, какие данные они обрабатывают.
• Спецификация OpenAPI для каждого публичного и партнёрского API — и проверка входящих запросов по схеме на шлюзе.
• План вывода старых версий: срок, уведомление клиентов, фактическое отключение.
• Тестовые и промежуточные стенды недоступны из интернета или закрыты авторизацией, в них нет боевых данных.
• Конфигурация: только TLS, CORS со списком конкретных доменов, ошибки без трассировок, отключённые неиспользуемые HTTP-методы и заголовки безопасности сайта на ответах.
• Журналы: кто, когда и к какому объекту обращался; отказы авторизации — отдельное событие для мониторинга, потому что серия отказов часто означает перебор.

Как встроить безопасность API в разработку

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

1. На этапе проектирования — модель угроз для новых методов: какие данные, какие роли, что будет при злоупотреблении.
2. В сборке — анализ кода (SAST), проверка зависимостей (SCA), валидация спецификации, автотесты на авторизацию.
3. На тестовом стенде — динамическое сканирование (DAST) по спецификации OpenAPI.
4. Перед крупным релизом и не реже раза в год — ручной пентест API по OWASP API Security Top 10 и методике OWASP WSTG. Как устроен такой проект и что должно быть в отчёте — в статье про пентест веб-приложения.
5. После находок — исправление по приоритетам и повторная проверка, как в любом процессе управления уязвимостями.

Чек-лист безопасности API перед релизом

• Каждый метод, принимающий идентификатор объекта, проверяет права на этот объект на сервере.
• Ответы формируются по схеме с явным списком полей; запись принимает только разрешённые поля.
• Административные методы закрыты проверкой роли, есть автотесты на отказ.
• Токены короткоживущие, подпись и параметры JWT проверяются, отзыв работает.
• В мобильном приложении и фронтенде нет секретных ключей.
• Настроены лимиты частоты, размера запросов и пагинации; платные внешние вызовы ограничены бюджетом.
• Есть реестр всех API и версий, старые версии отключены или имеют дату отключения.
• Тестовые стенды закрыты от интернета и не содержат боевых данных.
• CORS ограничен конкретными доменами, ошибки не раскрывают внутреннее устройство.
• Обращения сервера к внешним адресам идут только по списку разрешённых.
• Журналы фиксируют доступ к объектам и отказы авторизации, на них настроены оповещения.
• Перед релизом проведён ручной пентест API или он запланирован на ближайшее окно.

Как это делает Viviar

Безопасность API — часть направления кибербезопасности: ручной пентест по OWASP API Security Top 10, разбор кода и встраивание проверок в сборку. Пакет «Запуск безопасной разработки» — аудит одного продукта с разбором кода и списком того, что чинить, — стоит от 20 300 BYN; с внедрением SAST, DAST и SCA в сборку — от 43 600 BYN. В проектах разработки под ключ требования к авторизации, лимитам и журналам закладываются с первого спринта — сначала мы отрабатываем такие практики на собственных продуктах.

Частые вопросы

Что такое безопасность API простыми словами?

Безопасность API — это меры, которые не позволяют получить через программный интерфейс больше данных или действий, чем положено. Главное — проверка прав на каждый объект и функцию на сервере, надёжная аутентификация, лимиты запросов, учёт всех версий API и регулярное тестирование. Типичные риски перечислены в OWASP API Security Top 10 редакции 2023 года.

Какая уязвимость API самая распространённая?

В OWASP API Security Top 10 2023 года первое место занимает нарушение авторизации на уровне объекта (BOLA): сервер не проверяет, принадлежит ли запрошенный заказ, счёт или документ текущему пользователю. Закрывается централизованной проверкой владения объектом на сервере в каждом методе и автотестами, которые запрашивают чужой объект и ожидают отказ.

Достаточно ли автоматического сканера для проверки API?

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

Нужно ли защищать внутренний API, если он не опубликован?

Да. Адреса методов легко извлечь из мобильного приложения или кода фронтенда, а внутренние сервисы становятся доступны после компрометации любого узла сети. Внутренний API должен проверять аутентификацию и права так же, как публичный, а сетевые ограничения — дополнительный, а не единственный слой. Неучтённые API — отдельная категория OWASP API Security Top 10.

Сколько стоит проверка безопасности API?

Зависит от числа методов, ролей, версий и того, нужен ли разбор кода. У Viviar аудит одного продукта с разбором кода входит в пакет «Запуск безопасной разработки» от 20 300 BYN, а с внедрением автоматических проверок в сборку — от 43 600 BYN. Точный объём определяем после получасового разговора.

Вывод

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

Источники: OWASP API Security Top 10 (2023), OWASP Web Security Testing Guide, OWASP Application Security Verification Standard, OWASP REST Security Cheat Sheet, OWASP Authorization Cheat Sheet (owasp.org); OpenAPI Specification (openapis.org); RFC 6749 «The OAuth 2.0 Authorization Framework» и RFC 7519 «JSON Web Token» (ietf.org); OpenID Connect Core (openid.net).