что именно открываем наружу - список методов, права, границы доступа;
где данные могут утечь - логирование, тестовые ответы, заголовки, кэш;
как ломается авторизация - подмена токена, повторный запрос, лишние права;
что делаем при сбое - блокировка, алерт, откат, ручная проверка;
что оставляем в журнале - только то, что нужно для разбора, без лишних данных.
Я хочу показать не “аудит ради галочки”, а нормальную проверку перед тем, как API увидит внешний мир. Проблема часто не в одной дыре, а в том, что команда спешит и открывает интерфейс, не договорившись о правилах: кто имеет доступ, как ограничиваются запросы, что считается подозрительным поведением и кто реагирует, если что-то пошло не так. Без этого даже хороший технический продукт становится хрупким.
Отдельно проверьте ключи доступа, ротацию секретов и ограничения по частоте запросов. Очень часто проблема не в сложной атаке, а в слабом контроле базовых вещей. Если токен живет слишком долго, если его можно случайно засветить в логах или если ограничение по частоте запросов не настроено, вы сами создаете себе уязвимость. Безопасность здесь не в магии, а в дисциплине.
Еще одна частая ошибка - тестировать только “правильный” сценарий. Но безопасность живет именно в неправильных сценариях: что будет, если запрос повторить, если токен просрочен, если отправить лишнее поле, если клиент прислал поломанный формат, если два действия идут параллельно. Вот там и проверяется устойчивость. Хороший API не просто отвечает на нормальный запрос, он спокойно переживает странный.