Authenticated API coverage: без role-matrix бизнес-логика остаётся в тени
Синтетический research-shot: схема проблемы, контроля, evidence и ретеста в фирменной лабораторной стилистике Virusologia.
Коротко: Anonymous coverage полезен как perimeter-pass, но полноценный API-аудит начинается тогда, когда у вас есть несколько owned test identities, HAR, role matrix и сценарии жизненного цикла объекта.

Проблема

Без аутентифицированного слоя API-пентест видит много surface, но почти не видит смысл. Самые ценные проблемы прячутся не в 404 и не в headers, а в том, как роли создают, читают, меняют и одобряют объекты.

Даже если есть две роли, команда часто не строит coverage-matrix: какие методы были проверены, какие состояния объекта покрыты, где проверка read-only, а где нужно честно написать limitation.

Решение

Coverage должен строиться вокруг роли, объекта и его жизненного цикла. Не только endpoint, но и состояние объекта определяет риск: draft, pending approval, archived, exported, delegated, revoked.

Отчёт выигрывает, когда показывает не просто finding, а матрицу: какие роли и какие состояния протестированы, где есть evidence, а где coverage gap.

Что проверить руками

  • Подготовить минимум два owned test accounts и список ролей.
  • Собрать HAR/OpenAPI и карту object identifiers.
  • Пройти жизненный цикл хотя бы одного чувствительного объекта от создания до архивации/удаления.
  • Отдельно фиксировать, что не удалось проверить без state-changing approval.

Типичные ошибки

  • Путать authenticated coverage с простым login success.
  • Тестировать только статичные GET-маршруты и считать бизнес-логику покрытой.
  • Не показывать coverage gaps и создавать иллюзию полноты.

Defensive checklist

  • Есть role-matrix и object-lifecycle matrix.
  • Owned identities задокументированы и одобрены.
  • Coverage gaps явно отражены в отчёте.
  • Для validated finding есть differential evidence по ролям или состояниям.

Безопасный пример кода

Простейший coverage-matrix для role/state testing. Пример рассчитан на owned/lab-среду и показывает инженерную логику проверки, а не эксплуатационную цепочку.

coverage = {
  "owner": {"draft": "tested", "submitted": "tested", "archived": "gap"},
  "reviewer": {"draft": "denied", "submitted": "tested", "archived": "gap"},
  "admin": {"draft": "tested", "submitted": "tested", "archived": "tested"}
}

Как это должно попасть в отчёт

  • Матрица ролей, объектов и состояний.
  • Какие проверки были read-only и где требовалось отдельное approval.
  • Ретест: исправление проверяется на тех же ролях и состояниях.
Этическая рамка: материал предназначен для defensive security, исследования собственных систем, controlled labs и подготовки remediation. Здесь нет вредоносных payload-цепочек, persistence-инструкций и шагов для несанкционированного доступа.