Защита API от злоупотреблений: чек-лист перед продом

Что именно нужно защитить до релиза

API может быть формально закрыт авторизацией и всё равно оставаться уязвимым: пользователь с обычным токеном перебирает идентификаторы заказов, бот создаёт тысячи заявок, а повтор платежного запроса списывает деньги дважды. Этот чек-лист рассчитан на ревью перед продакшеном и опирается на OWASP API Security Top 10 2023; конкретные лимиты нужно вывести из измерений вашего сервиса.

Главная ошибка — проверять только сценарий «правильный пользователь отправил правильный запрос». Безопасность API проверяется на границах: что произойдёт при смене идентификатора, повторе запроса, превышении скорости, истечении токена и отказе внешней зависимости.

Авторизация отвечает на вопрос «кто вы», а защита API должна дополнительно ответить на вопросы «что именно вам можно», «как часто» и «какой ущерб допустим».

1. Зафиксируйте границы API и модель угроз

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

• Отдельно отметьте операции входа, восстановления доступа, отправки кодов, создания заказов, платежей и загрузки файлов.
• Разделите данные по чувствительности: публичные, пользовательские, финансовые, административные.
• Зафиксируйте внешние зависимости: база данных, платёжный провайдер, очередь, файловое хранилище, сторонний API.
• Для каждого endpoint’а укажите максимальный ожидаемый размер запроса и ответа.

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

Сноска. BOLA (Broken Object Level Authorization) — ошибка, при которой сервер проверяет право на сам тип операции, но не проверяет, имеет ли конкретный пользователь доступ к объекту с указанным идентификатором.

2. Проверьте аутентификацию и жизненный цикл токенов

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

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

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

3. Проверьте доступ к объектам и массовое назначение полей

Самый полезный тест для API с пользовательскими данными — повторить запрос с тем же токеном, но изменить идентификатор объекта. Если ответ или изменение проходят, сервер доверяет данным клиента сильнее, чем должен.

Минимальный набор негативных проверок

1. Создайте два тестовых аккаунта и по одному объекту для каждого.
2. С токеном первого аккаунта запросите объект второго по его идентификатору. Ожидаемый результат — отказ или ответ без раскрытия существования объекта, в зависимости от модели API.
3. Попробуйте изменить владельца, роль, статус, цену или признак подтверждения через тело запроса. Эти поля должны задаваться сервером или отклоняться.
4. Проверьте доступ к объекту после удаления, блокировки пользователя и отзыва роли.

Проверка результата: тесты падают, если идентификатор объекта заменили, а клиент получил чужие данные или изменил поле, которое не должен контролировать.

4. Настройте ограничения скорости и стоимости

Один глобальный лимит на IP редко решает проблему. Пользователь может работать через мобильную сеть, бот — распределять запросы по адресам, а несколько клиентов за одним NAT начнут мешать друг другу.

Для превышения лимита используйте понятный отказ. В HTTP API это обычно статус 429 Too Many Requests; если клиенту известен момент следующей попытки, передавайте корректный Retry-After. Не рассчитывайте только на задержку в интерфейсе: ограничение должно работать на сервере.

5. Защитите дорогие и повторяемые операции

Повтор запроса особенно опасен там, где действие имеет побочный эффект: создаёт платёж, письмо, заказ или задачу в очереди. Клиент может повторить запрос из-за тайм-аута, а прокси или библиотека — повторить его автоматически.

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

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

6. Проверьте входные данные и ответы

Валидация должна выполняться на сервере и соответствовать контракту конкретного endpoint’а. Проверяйте типы, обязательность, диапазоны, размер строк, вложенность JSON, MIME-тип и фактический размер загружаемого файла.

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

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

7. Что должно быть видно в продакшене

Без телеметрии команда узнает о злоупотреблении по жалобам или счёту облачного провайдера. Логи и метрики должны позволять связать запрос с endpoint’ом, результатом и вызывающей стороной, не сохраняя содержимое секретов.

• Считайте запросы по маршруту, статусу, клиенту, региону или другой безопасной группировке.
• Отслеживайте долю ответов 401, 403, 404, 429 и 5xx.
• Отдельно измеряйте время и объём ресурсов для дорогих операций.
• Настройте оповещение на резкий рост отказов, перебор идентификаторов и необычное число повторов.
• Проверьте, что корреляционный идентификатор проходит через API, очередь и внешние вызовы.

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

Что ломается чаще всего

Когда чек-лист можно считать пройденным

Ревью завершено не тогда, когда все пункты получили статус «настроено». Для каждого контроля должен существовать тест, наблюдаемая метрика и понятный владелец. Если лимит есть, но никто не знает, что произойдёт при его превышении, это не защита, а скрытая точка отказа.

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

Что делать дальше

После релиза поставьте на дашборд четыре показателя: долю 401 и 403, частоту 429, долю 5xx и стоимость самых тяжёлых endpoint’ов. Через неделю сравните их с базовой линией из тестовой среды. Затем пересмотрите лимиты по фактическим пикам, а не по предположениям, и добавьте в CI негативные тесты на доступ к чужим объектам и повтор побочных операций.