Как защитить REST API от перебора и брутфорса без блокировки легитимных пользователей

[kira_api82]

Разрабатываю REST API на Node.js/Express. Есть эндпоинт /api/login и /api/reset-password. По OWASP API Security Top 10 это классические цели для брутфорса. Хочу добавить защиту, но боюсь перегнуть палку и заблокировать нормальных пользователей — например, мобильное приложение иногда делает несколько запросов подряд при переподключении. Как найти баланс?

[alex_api23]

Базовый подход — rate limiting по нескольким осям одновременно: по IP (грубая защита от ботов), по аккаунту/логину (защита от распределённых атак с разных IP на один аккаунт), и по user-agent/device fingerprint (дополнительный сигнал). Библиотека express-rate-limit + rate-limit-redis позволяет настроить всё это гибко. Для /login типичные настройки: 5 попыток в 15 минут по IP, 10 попыток в час по имени пользователя.

[svetlana_official]

Важный паттерн — экспоненциальный backoff вместо жёсткой блокировки. После 3 неудачных попыток — задержка 1 секунда, после 5 — 5 секунд, после 10 — 30 секунд, после 20 — временная блокировка на 15 минут с уведомлением пользователю на почту. Это сильно затрудняет перебор но не ломает легитимное использование. Реализуется через Redis с TTL-ключами.

[aissh4380]

Для проблемы с мобильным приложением при переподключении — убедись что клиент не шлёт login-запросы при каждом reconnect. Правильный паттерн: JWT с refresh token, где основной токен живёт 15-60 минут, а refresh — дни/недели. Переподключение должно использовать refresh endpoint, а не повторно логиниться. Это и UX улучшает, и нагрузку на защитные механизмы снижает.

[natalia2813]

Из более продвинутого — CAPTCHA только при аномальном поведении (не для всех подряд). Сервисы типа Cloudflare Turnstile или hCaptcha можно подключить так: первые N попыток проходят свободно, при превышении порога — запрашивается CAPTCHA. Пользователь не замечает защиты пока не начинает вести себя «подозрительно».

[lev7399]

Не забывай про OWASP API4:2023 — Unrestricted Resource Consumption. Защита от брутфорса это часть более широкой темы. Ещё стоит: логировать все неудачные попытки с IP, user-agent, timestamp и отправлять в SIEM или хотя бы в алерты; использовать Have I Been Pwned API для проверки паролей при регистрации (чтобы пользователи не ставили слитые пароли); добавить заголовок `X-Content-Type-Options`, `X-Frame-Options` и убедиться что ответы на неудачный логин не раскрывают существование аккаунта (одинаковый ответ для «нет такого логина» и «неверный пароль»).

[ksenia_dns]

Практическая рекомендация по тестированию своей же защиты: используй hydra или ffuf для имитации брутфорса против staging-окружения. Команда `ffuf -w passwords.txt -u https://staging.api/login -X POST -d 'username=admin&password=FUZZ' -fc 200` покажет насколько реально твоя защита работает. Запускай это в CI как часть security-тестов.