Чек-лист API: контракт, права и наблюдаемость

Проверяйте API по согласованному контракту и модели доступа. Чек-лист помогает выбрать сценарии, но не доказывает отсутствие всех уязвимостей.

Контракт и документация

• Сверьте метод, путь, обязательные поля, типы и ограничения. Пример из документации должен выполняться на тестовых данных.
• Проверьте корректный, пустой и неполный запрос; неизвестное поле и неверный тип.
• Сверьте коды HTTP и структуру ошибки. В ответе не должно быть stack trace или внутренних секретов.

Аутентификация и авторизация

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

Для браузерной cookie-сессии рассмотрите CSRF по модели угроз. Для XSS важен контекст, в котором клиент выводит данные. Нельзя применить одно слово «защита» одинаково ко всем API.

Данные и повторные запросы

• Проверьте границы длины/числа, null, Unicode и SQL-подобные строки как данные, а не код.
• Убедитесь, что ответ не содержит лишних свойств другого пользователя или внутренних полей.
• Для операций создания проверьте дублирование запроса и ожидаемую идемпотентность.

Нагрузка и диагностика

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

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