Маркетинговый API ломают не «хакеры из кино», а обычный брутфорс по ключам и токенам

Маркетинговый API ломают не «хакеры из кино», а обычный брутфорс по ключам и токенам

Если API принимает длинный хвост запросов без ограничений, его начинают перебирать: ключи, секреты, одноразовые токены, refresh-токены. Самый частый провал — открытый endpoint без rate limit и без блокировки по IP/ASN. Второй — одинаковые ответы на «верный» и «неверный» ключ: атакующему не нужен доступ, ему нужна разница в поведении.

Базовая защита выглядит скучно, и это хорошо: • rate limit на уровень endpoint и клиента • экспоненциальная задержка после неудачных попыток • lockout по подозрительной активности • отдельный лимит на генерацию токенов • короткий TTL для access token и ротация секретов. Для серверов с высоким трафиком лучше выносить ограничения на reverse proxy или API gateway, а не городить логику в приложении.

Обязательно логируйте: IP, user-agent, идентификатор клиента, причину отказа, частоту ошибок. На этих данных строится бан по паттерну, а не по одному событию. Параллельно закрывайте лишнее: whitelist для внутренних интеграций, mTLS для сервис-сервис, только HTTPS, запрет анонимных методов, отдельные ключи для каждой интеграции. SSH тут не помогает, если наружу торчит слабый API.

Проверяйте, что после 3-5 неудачных попыток клиент получает одинаковый ответ и не может угадать, где был валидный токен. Стабильность — это отсутствие магии, только предсказуемая конфигурация. Разворачиваем, проверяем, мониторим.