Проверка авторизации API: доступ к данным и операциям

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

Проверка полезна для интерфейсов, где несколько ролей или организаций работают с общими типами объектов. Её планируют по правилам предметной области, а не только по списку адресов.

Перед релизом

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

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

После изменения ролей, фильтров или экспорта

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

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

Граница с аутентификацией и общим аудитом API

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

Валидацию токенов, транспорт, лимиты ресурсов, конфигурацию и внешние вызовы охватывает общая проверка безопасности API. Здесь результат ограничен правами и связанными условиями операций. Согласно OWASP Authorization Cheat Sheet ↗, права проверяют на каждом запросе, а неявный доступ по умолчанию запрещают. Конкретные разрешения определяет система, не сама рекомендация.

Шесть измерений ниже — рабочая модель для составления тестов, а не официальный формат OWASP. Она помогает заметить различия, которые скрываются за коротким утверждением «метод доступен сотруднику».

Субъекты и организации

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

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

Объекты, поля, операции и состояния

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

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

Условный пример. Сервис заявок обслуживает организации А и Б. Сотрудник видит только собственные заявки своей организации и меняет их тему в состоянии «черновик». Администратор видит заявки своей организации, внутренние комментарии, выполняет экспорт и подтверждает заявку в состоянии «на согласовании». Заявка claim-842 принадлежит сотруднику А и находится на согласовании. Организационные администраторы не имеют глобальных прав.

Положительные и отрицательные ожидания

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

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

Сохраните разрешённый запрос как основу. Меняйте одну значимую переменную и фиксируйте её в тесте; прямой вызов API исключает влияние скрытых кнопок и клиентских фильтров. Перед каждой изменяющей попыткой восстанавливайте исходные данные.

Доступ к чужому объекту и граница организаций

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

Нарушение называют BOLA — Broken Object Level Authorization, ошибкой авторизации на уровне объекта. IDOR — Insecure Direct Object Reference, небезопасная прямая ссылка на объект — обозначает связанную проблему доступа через переданный идентификатор. Руководство по тестированию безопасности веб-приложений WSTG 4.2, проверка IDOR ↗ описывает использование объектов другой тестовой учётной записи. Непредсказуемый идентификатор затрудняет угадывание, но не заменяет проверку полномочий.

Функции и административные операции

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

В условном сервисе сотрудник А не подтверждает claim-842, хотя вправе её читать. Администратор А подтверждает заявку на согласовании, но администратор Б не получает это право. Проверка функции и проверка принадлежности объекта закрывают разные условия; одного из них недостаточно.

Поля ответа и массовое присваивание

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

Массовое присваивание, или mass assignment, возникает, когда переданные поля автоматически меняют свойства объекта без необходимого ограничения. Добавьте в корректный изменяющий запрос запрещённое служебное поле. Сервер может отклонить запрос или игнорировать поле по контракту, но не должен выполнять запрещённое изменение. Эти риски чтения и изменения свойств объединены в OWASP API3:2023 ↗.

Переходы состояния и экспорт

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

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

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

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

Воспроизводимость и влияние

Согласно RFC 9110 ↗, 401 относится к отсутствию действительных аутентификационных полномочий, 403 — к отказу выполнить понятый запрос. Сервер может использовать 404, чтобы не раскрывать существование запрещённого ресурса. Выбор кода должен соответствовать HTTP и контракту; разные коды сами по себе не доказывают уязвимость.

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

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

Серверное правило и регрессионный тест

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

После исправления повторите исходный отрицательный сценарий и разрешённый контрольный запрос на целевой сборке. Проверьте данные и побочные эффекты, а не только сообщение об отказе. Добавьте тест в регулярную проверку изменений, закрепите исходные данные и владельца правила. OWASP Authorization Testing Automation Cheat Sheet ↗ показывает применение матрицы прав к автоматизированным тестам; она не гарантирует полного охвата предметной области.

Перед завершением проверки убедитесь, что результат не ограничен одним удобным сценарием:

• Тест только без токена. Добавьте запрос с действительными полномочиями, но без нужного права.
• Одна роль или организация. Сравните разрешённый доступ и запрет для других субъектов.
• Проверено только чтение. Включите изменения, административные действия и экспорт.
• Доверие к сложному идентификатору. Проверьте известный чужой тестовый объект.
• Фильтр только на клиенте. Отправьте корректный запрос напрямую и изучите ответ сервера.
• Пропущены список и файл экспорта. Проверьте состав выборки и доступ к результату фоновой задачи.
• Закрытие по факту правки. Повторите запрет и разрешённую операцию на целевой версии.

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