Безопасность API: что проверить перед выпуском и при аудите

Безопасность API проверяют по тому, какие данные и операции доступны конкретному пользователю, приложению или внешней системе. API — программный интерфейс, через который системы обмениваются запросами и результатами. Перед выпуском или при аудите сначала составляют перечень действующих адресов, версий и критических сценариев. Затем проверяют подлинность вызывающей стороны, права на объекты и поля, ограничения ресурсов, бизнес-операции, конфигурацию и внешние обращения. Для каждого сценария заранее определяют разрешённый результат и запрет, а после теста сохраняют ответ и изменения в системе. На выходе нужны карта покрытия, подтверждённые проблемы, ответственные и условия повторной проверки. Наличие токена и успешный отчёт сканера не заменяют эти доказательства. Проверка относится к согласованной версии и среде, а не гарантирует безопасность всех будущих изменений.

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

Перед выпуском

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

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

При аудите действующего API

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

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

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

Когда нужна отдельная проверка кода или клиента

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

Области ниже основаны на OWASP API Security Top 10:2023 ↗, перечне распространённых рисков безопасности API от международного сообщества OWASP. Это ориентир для охвата, не готовый набор тестов и не обязательная российская норма. Конкретные требования определяют данные, архитектура и условия применения системы.

До тестирования нужны согласованные ожидания и управляемые тестовые данные. Без них нельзя уверенно отделить уязвимость от разрешённого поведения или ошибки самого теста.

Инвентаризация хостов, маршрутов и версий

Для каждого доступного интерфейса записывают доменное имя, среду, версию, HTTP-метод, путь, владельца и предполагаемых потребителей. HTTP — протокол передачи запросов и ответов; метод задаёт тип обращения. Маршрут запроса — конкретное сочетание метода и адреса, а не только название функции. Учитывают внешние и внутренние входы, старые версии, служебные методы и интерфейсы, которых нет в актуальном описании.

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

Контракт, роли и тестовые данные

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

Проверяющим нужен способ увидеть результат за пределами HTTP-ответа: состояние объекта, созданную задачу, подготовленный файл или журнал события. Заранее согласуют очистку тестовых записей, отключение реальных уведомлений и допустимые пределы нагрузки. Реальные секреты и персональные данные не включают в общий отчёт; чувствительные доказательства хранят с ограничением доступа.

Критические операции и внешние зависимости

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

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

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

Подлинность и токены

Аутентификация устанавливает, кто обращается к системе; авторизация определяет, что ему разрешено. Проверьте запрос без полномочий, с повреждённым или просроченным токеном, а также после отзыва доступа. Если используется подписанный токен, сервер должен проверять его подлинность и применимые ограничения, а не просто читать содержащиеся поля.

Проверьте, предназначены ли полномочия для данного сервиса и среды. Уточните поведение после выхода, блокировки пользователя и смены роли: срок действия и задержка применения изменений зависят от выбранной схемы. Не обещайте немедленный отзыв там, где он не предусмотрен. Секреты не должны попадать в адрес запроса или доступные посторонним журналы. Публичные обращения защищают HTTPS — передачей HTTP поверх защищённого соединения; защищённый транспорт не заменяет проверку прав.

Права на объект, функцию и поле

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

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

Ресурсы, бизнес-потоки и ограничения

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

Для критического сценария проверяют порядок действий, повтор запроса и параллельные попытки. Отдельный запрос может быть корректным, но многократное разрешённое действие — создавать недопустимый расход или обходить условия операции. Например, автоматическое массовое резервирование может требовать ограничений сверх проверки роли. Это отличается от простого запрета чужого объекта. Конкретные пороги выбирают по работе сервиса; универсального числа запросов для всех API нет.

Конфигурация, версии и сторонние API

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

Внешние адреса требуют отдельной проверки SSRF — подделки запроса со стороны сервера, при которой приложение можно заставить обратиться к нежелательному ресурсу. На безопасном тестовом стенде проверяют допустимые схемы, хосты и адреса после разрешения имени, обработку перенаправлений и доступ к внутренним ресурсам. Одной проверки текстового префикса адреса недостаточно. Возможные защитные меры и границы описаны в OWASP API7:2023 ↗.

Ответ стороннего API тоже проверяют: схему, размер, время ожидания и допустимые значения. Ошибка партнёра не должна автоматически становиться разрешением операции или попадать без обработки в чувствительные команды. Для облачных систем руководство американского Национального института стандартов и технологий NIST SP 800-228 upd1 ↗ рассматривает меры до запуска и во время эксплуатации; применять их следует с учётом архитектуры и риска.

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

Покрытие и ограничения

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

Для детализации требований можно использовать OWASP ASVS 5.0.0 ↗ — стандарт проверки безопасности приложений. Выбранный пункт связывают со сценарием и доказательством, сохраняя версию и идентификатор требования. Соответствие отдельным пунктам не означает прохождения всего стандарта или сертификации. Открытые ограничения и исключения остаются частью результата, даже если все доступные тесты завершились успешно.

Условный пример. В каталоге заказов организаций А и Б работают версии v1 и v2. Сотрудник А вправе читать свои заказы, администратор А — экспортировать только данные А и подтверждать её заказы после проверки реквизитов. Чтение публичного справочника типов заказов доступно без входа; сами заказы публичными не являются. Ни одна роль Б не получает права на данные А.

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

Успешное чтение одного маршрута v2 не подтверждает безопасность экспорта v1. Исправление фильтра в новой версии также не закрывает старый доступ. В этом примере повторно проверяют обе версии, роль Б и состав выгрузки, включая фоновое создание файла и его получение.

Находка, ответственный и повторная проверка

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

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

Типовые ограничения результата стоит проверять до релизного решения:

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

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