Почему это важно
Ответ HTTP 200 без личности и контекста решения не объясняет, кто получил данные и почему; запись самого секрета, наоборот, создаёт новую утечку.
Что подтверждено
Рекомендации NIST требуют для контроля API как минимум время, идентификатор клиента, состояние запроса и ответа и идентификатор конечной точки.
Граница применимости: Рабочая телеметрия API по NIST SP 800-228.
Аудит должен сохранять личность и контекст решения без самого токена на предъявителя или ключа API: секреты в URI и журналах становятся повторно используемой утечкой.
Граница применимости: Доказательство действий API без раскрытия учётных данных.
Что проверить
- Запишите клиента, субъект и конечную точку.
- Добавьте решение, результат и идентификатор связи.
- Не записывайте сами учётные данные.
Первоисточники
Guidelines for API Protection for Cloud-Native Systems
National Institute of Standards and Technology · NIST SP 800-228-upd1, includes updates as of 13 March 2026
Задаёт API lifecycle controls для authentication, authorization, rate limits, resource limits, logging и monitoring.
Открыть первоисточникThe OAuth 2.0 Authorization Framework: Bearer Token Usage
Internet Engineering Task Force · RFC 6750, October 2012
Определяет bearer-token presentation, защиту от disclosure, Authorization header и ошибки invalid_token/insufficient_scope.
Открыть первоисточникBest practices for managing API keys
Google Cloud · Google Cloud documentation, checked 30 August 2026
Рекомендует ограничивать keys, хранить вне code и query parameters, регулярно rotate и удалять ненужные keys.
Открыть первоисточникSecurity and Privacy Controls for Information Systems and Organizations
National Institute of Standards and Technology · NIST SP 800-53 Rev. 5, Release 5.2.0
Содержит controls для authorization, least privilege, separation of duties, privileged functions и protection of audit information.
Открыть первоисточник