Защита API от злоупотреблений: типичные ошибки и решения

Почему одного лимита запросов недостаточно

Если API ограничивает только число запросов с одного IP, злоумышленник может распределить нагрузку между адресами. Если лимит привязан только к аккаунту — создать несколько аккаунтов или использовать скомпрометированные учётные записи. А иногда сервис перегружает не поток запросов, а один дорогой endpoint: например, поиск с широкими фильтрами или экспорт большого отчёта.

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

Ошибки, из-за которых лимиты обходят

Считать запросы только по IP

IP полезен как один из сигналов, но ненадёжен как единственный ключ: за одним адресом могут находиться пользователи мобильного оператора или компании, а один атакующий может менять адреса. Жёсткий общий лимит по IP способен заблокировать добросовестную аудиторию; высокий лимит оставит злоупотребление почти без препятствий.

Сочетайте ключи: IP или подсеть, учётную запись, API-ключ, а для отдельных операций — ресурс, который меняется. Учитывайте доверенные прокси только из явно настроенного списка. Если приложение принимает заголовок с адресом клиента от любого отправителя, его можно подделать.

Ставить одинаковую квоту на все операции

Запрос на чтение небольшого объекта и генерация отчёта могут стоить серверу несопоставимо разных ресурсов. Общая квота не учитывает эту разницу. Установите отдельные бюджеты для дорогих операций и ограничивайте объём работы: размер страницы, число объектов в запросе, диапазон дат, время выполнения. Порог выбирайте по измеренной нагрузке и допустимой стоимости, а не по удобному круглому числу.

Проверять лимит после тяжёлой работы

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

Забывать про бизнес-операции

Число HTTP-запросов не всегда отражает ущерб. Повторные попытки оплатить, отправить приглашения или заказать SMS могут обходиться дороже обычного чтения данных. Вводите лимиты на такие действия по аккаунту и целевому объекту, а для повторяемых операций проектируйте безопасную обработку дублей. Важно не превращать это в запрет легитимных повторов после сетевой ошибки.

Возвращать слишком подробную ошибку

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

Соберите защиту из нескольких уровней

У каждого подхода своя цена: чем точнее контроль, тем больше состояний и сигналов надо поддерживать. Таблица — не готовые пороги, а схема выбора слоя.

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

Как проверить защиту без догадок

1. Составьте список дорогих и чувствительных операций. Для каждой укажите, какие ресурсы она потребляет и какой ущерб возможен при повторении. Проверка: у команды есть перечень endpoint’ов с владельцем и обоснованием ограничений.
2. Определите ключи ограничения. Для анонимных запросов используйте доступные сетевые сигналы, для авторизованных — учётную запись или выданный ключ; для бизнес-операций добавьте целевой объект. Проверка: смена одного признака не снимает все ограничения одновременно.
3. Задайте пределы объёма и параллельности. Ограничьте размер тела, размер страницы, диапазон выборки и количество одновременно выполняемых дорогих задач. Проверка: запрос с максимальным допустимым объёмом не выходит за установленный бюджет ресурсов.
4. Согласуйте поведение при отказе. Возвращайте корректный статус, а клиентам — понятные правила повторной попытки. Проверка: тестовый клиент не запускает бесконечные повторы при ответе 429.
5. Проведите тесты на обход и ложные срабатывания. Проверьте несколько аккаунтов, общие IP, смену адреса, параллельные запросы и повтор бизнес-действия. Проверка: ограничения срабатывают на ожидаемом уровне, а обычный сценарий за общим адресом остаётся доступен.
6. Добавьте наблюдаемость. Измеряйте отказы по endpoint’у и причине, долю запросов с ограничением, глубину очереди и нагрузку на базу. Проверка: дежурный может отличить атаку от неверно настроенного лимита без сбора секретов и лишних персональных данных.

Лимит полезен не тогда, когда он просто отклоняет запросы, а когда он ограничивает стоимость злоупотребления и оставляет рабочий путь легитимному клиенту.

Где защита ломается

Общий IP и ложная блокировка. Если ограничивать всех пользователей за одним адресом одинаково, массовый офис или мобильная сеть могут исчерпать квоту. Разделяйте сетевой сигнал и лимиты аутентифицированного клиента, а изменения проверяйте на реальных сценариях.

Распределённые экземпляры приложения. Если каждый сервер считает запросы независимо, суммарный лимит может оказаться выше ожидаемого. Проверьте, где хранится состояние ограничителя и как оно ведёт себя при сбое этого хранилища. Выбор fail-open или fail-closed — компромисс между доступностью и риском: его определяют отдельно для каждой операции.

Синхронная проверка на каждый запрос. Централизованное хранилище счётчиков помогает согласовать квоты, но само может стать узким местом. Измеряйте задержку проверки и отказоустойчивость ограничителя под нагрузкой; не считайте его бесплатной частью инфраструктуры.

Защита только на периметре. Шлюз не всегда знает цену бизнес-операции и идентичность пользователя на уровне приложения. Поэтому проверка на краю дополняет, но не заменяет ограничения в приложении и бюджеты ресурсов.

Тихая блокировка без метрик. Если логи не содержат причины отказа и идентификатора операции, сложно понять, сработала ли защита или сломался клиент. При этом не записывайте токены и секреты. Для анализа достаточно безопасных идентификаторов, категории ограничения и временной метки.

Rate limiting¹ часто переводят как «ограничение частоты запросов». На практике это правила, которые ограничивают число или стоимость действий за период; конкретная схема может учитывать не только количество HTTP-запросов.

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

Начните с журналов и профиля нагрузки: найдите операции с наибольшей стоимостью, частотой ошибок и долей повторов. Затем добавьте ограничения по слоям и проверьте сценарии обхода вместе с ложными срабатываниями. После запуска следите не за одним числом запросов, а за задержкой API, расходом ресурсов, глубиной очередей и долей отказов 429. Поведение HTTP-статусов и повторных запросов сверяйте с RFC 9110, а типовые риски API — с OWASP API Security Top 10 2023.