Маркетинговые API ломают не “хакеры”, а слабая защита от брутфорса

Маркетинговые API ломают не “хакеры”, а слабая защита от брутфорса

Почти всегда вход выглядит одинаково: endpoint авторизации, токеновый обмен, интеграционный ключ, webhook-панель. Если на них нет ограничений, атакующий просто перебирает пары логин/пароль, client_id/secret или токены до первого успешного ответа. Для API это опаснее, чем для формы входа: запросы дешёвые, автоматизируются легко, а шум в логах долго выглядит как обычная активность.

Что ставить в базу защиты:
— rate limit по IP, по учётке и по ключу;
— exponential backoff после неудачных попыток;
— блокировку после N ошибок с таймаутом;
— отдельные лимиты на /auth, /token, /refresh, /webhook;
— allowlist для сервисных IP, если интеграция закрытая.
Если у вас только IP-limit, его обойдут через прокси. Если только account-limit, атакуют с распределённых адресов. Нужны сразу несколько слоёв.

Дальше — наблюдаемость. Логируйте 401/403, счётчик попыток, ASN, User-Agent, время между запросами. Алерт нужен не на сам факт ошибки, а на паттерн: серия коротких запросов, одинаковый payload, скачок по уникальным IP, рост отказов по одному ключу. Без этого вы узнаете о проблеме уже после утечки токена или массового спама.

Не забывайте про гигиену ключей: короткий TTL для access token, ротация refresh token, подпись запросов HMAC, запрет пустых секретов и хранение ключей только в secret manager. Если API наружу не нужен — прячьте его за VPN, WAF или mTLS. Стабильность — это отсутствие магии, только предсказуемая конфигурация.

Разворачиваем, проверяем, мониторим. Если защита от брутфорса не описана в конфиге и не видна в метриках, её у вас нет.