На эндпоинтах API нет rate limit. Боты шлют миллионы запросов и тормозят сервер. Сколько запросов в секунду должно быть разрешено?
Как настроить rate limit? Возвращается ли информация в заголовках? Как предупредить разработчика мобильного приложения?
API-ключи есть, но все используют один и тот же. Нужно ли ставить лимит на каждого пользователя?
Ограничение частоты запросов API (Rate Limiting): защита от DDoS + защита от злоупотреблений. Лимиты: 1) Глобальные (на весь сервер): 10000 зап/мин, 2) На пользователя/API-ключ: 100 зап/мин, 3) На эндпоинт: GET /users 1000/мин, POST /users 100/мин. Типы: 1) Фиксированное окно (счетчик за минуту), 2) Скользящее окно (плавающее время, точнее), 3) Токен-бакет (разрешение на всплески). Реализация: 1) HTTP-заголовки (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset), 2) Коды ответа (429 Too Many Requests), 3) Заголовок Retry-After (отправка ожидаемого времени повторной попытки), 4) База данных лимитов (Redis оптимален, учет запросов по ключу). Отслеживание по пользователям: API-ключ/токен (уникальный идентификатор), ID пользователя (если авторизован), IP-адрес (для анонимных). Обработка превышения: 1) Немедленный отказ (ответ 429), 2) Очередь (отложенный ответ), 3) Троттлинг (замедление ответа). Лучшие практики: ступенчатые лимиты (бесплатный тариф: 100/мин, платный: 1000/мин), резерв по IP (если нет авторизации), разрешение на всплески (Token bucket: 100 обычных, 500 всплеск). Обработка в мобильном приложении: стратегия backoff (экспоненциальная: 1с → 2с → 4с), обработка ошибок (показывать сообщение 'rate limited', повторить позже), кэширование (минимизировать вызовы API).
Doki · Тест на проникновение · 2024
Ставь rate limit для начала 100 зап/мин на пользователя. Подними redis трекай кол-во запросов по ключу. честно отправляй 429 при превышении лимита. Задокументируй хедеры для мобилы — x-ratelimit-remaining...
P.S.: вопрос уже задавали ниже, ответ во втором сообщении.
Реализация rate limiting: 1) алгоритм token bucket (псевдокод: bucket_tokens = min(max_tokens, bucket_tokens + rate*elapsed_time), при запросе: if bucket_tokens >= 1 → уменьшить, иначе 429), 2) структура ключей Redis (user_id:rate_limit → увеличить, expire 60s), 3) HTTP заголовки (response.setHeader('X-RateLimit-Limit', 100), 'X-RateLimit-Remaining', tokens_left, 'X-RateLimit-Reset', reset_time), 4) лимиты по эндпоинтам (конфиг middleware: маппинг route → limit). Размещение: API gateway (AWS API Gateway, Kong) обрабатывает rate limiting до логики приложения или на уровне приложения (middleware: express-rate-limit, Flask-Limiter). Мониторинг: алерт при приближении к лимиту (80%), блокировка повторных нарушителей (IP blacklist), постепенное наказание (увеличение задержек).
ставь rate limit, 100 зап/мин на юзера. в Redis держи счетчик токенов. если лимит превышен, кидай 429 + заголовок Retry-After... в общем мобиильным разработчикам посоветуй 'exponential backoff' — после бота ретраить с задержкой. если общий API-ключ выдавай ключи каждому отдельно...
Стратегия ограничения частоты запросов: 1) Многоуровневая система (бесплатно: 100/мин, про: 1000/мин), 2) Чувствительность эндпоинта (чтение: высокий лимит, запись: низкий лимит), 3) Разрешение на всплески (размер корзины > скорость — пользователи могут делать кратковременные пиковые нагрузки), 4) Классификация пользователей (аутентифицированные: выше лимит, анонимные/IP: ниже лимит). Метрики мониторинга: доля ответов 429 (отслеживание паттернов злоупотребления), тренды использования API (планирование мощностей), одновременные пользователи (оценка нагрузки). Устойчивость на стороне клиента: экспоненциальная задержка (задержки 1с, 2с, 4с, 8с) джиттер (рандомизация для предотвращения "стада оленей"), постановка запросов в очередь (пакетная обработка в часы низкой нагрузки).
в теории верно но на практике так не работает. спешка в решеиях оборачивается исправлениями через полгода.
это мое мнение не утверждаю, что оно единственно верное.
У меня нет опыта в безопасность API, rate limit, поэтому и спрашиваю. Меры, принятые без инвентаризации, оставляют открытыми двери, о которых вы не знаете.
Спешка в решениях оборачивается исправлениями через полгода. Если напишете результат здесь, это поможет и другим.
После того случая мой взгляд на вещи изменился. Две недели ведения заметок дают лучший результат, чем шестимесячные прогнозы.
Надеюсь, это будет полезно.
Хочу предупредить. Ответ сильно зависит от отрасли, универсального правила нет.
Если напишете результат здесь, это поможет и другим.
Я тоже так считаю. Непроверенная резервная копия — не резервная копия.
Начните с небольшого эксперимента, не привязывайте всё сразу. Удачи.
Хочу задать вопрос. Если на один вопрос вы получаете три разных ответа, вопрос задан неправильно.
На этом всё, извините, если затянул.
Doki · Корпоративный сайт · 2024
Я думаю иначе. То, что делают все, не значит, что это правильно.
Без измерений мы всегда приходим к одному и тому же. Проверено опытом.
Пишу это, чтобы вы не совершили ту же ошибку. Если разрешение и объем тестирования не зафиксированы письменно, тест не начинать.
Проверено опытом.
Хочу добавить, так как на форуме это часто упускают: время обнаружения проблемы напрямую определяет её стоимость. Ускорение обнаружения часто обходится дешевле, чем инвестиции в предотвращение.
Нужно идти по порядку. Больше всего времени у нас уходило на то, что было непонятно, кто принимает решения.
Надеюсь, это будет полезно.