Боты в 2026 году: где заканчивается CDN/WAF и начинается фрод-экспертиза

На панели мониторинга все спокойно: сервис доступен, критических срабатываний нет. При этом растут расходы на SMS, появляются фиктивные аккаунты, а платежная форма получает подозрительные обращения. Причина может скрываться в автоматизации, которая использует штатные функции приложения. Как заметить такую активность и остановить ее до ущерба?

Атака без всплеска: почему запросы проходят фильтры

Лимит запросов с одного IP помогает сдерживать простую автоматизацию. Но если скрипт использует множество адресов и выдерживает паузы, каждый источник может оставаться в разрешенных пределах. Сервис продолжает обслуживать обращения, хотя их совокупность уже создает проблему.

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

По данным F6, на защищаемых ресурсах доля бот-трафика составляла 30% в 2023 году, 39% в 2024-м и 41% по итогам 2025-го. В прогнозе на 2026 год специалисты компании ожидали дальнейшего роста.

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

Что добавляет фрод-экспертиза

CDN/WAF может включать частотные ограничения, проверку IP-репутации, выявление веб-атак и развитые механизмы bot management. Набор возможностей зависит от платформы и конфигурации. Универсальной границы, после которой любой CDN/WAF перестает видеть угрозу, нет.

Практический вопрос — хватает ли вашей системе данных, чтобы распознать конкретный сценарий.

Например, запрос на отправку кода соответствует формату API. Регистрация проходит обязательные проверки. В платежной форме заполнены все поля. Но зачем выполняются эти действия: для входа клиента, получения очередного бонуса или тестирования чужой карты?

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

Так безопасность веб-приложений охватывает злоупотребление штатными функциями сервиса. Preventive Proxy отвечает за выявление и ограничение вредоносной автоматизации до обработки запросов бизнес-логикой приложения.

Четыре способа использовать приложение против бизнеса

1. Расходовать SMS-бюджет

Функция отправки одноразовых кодов удобна для пользователей и привлекательна для атакующего: каждое сообщение оплачивает компания. Скрипт может многократно вызывать эту функцию, меняя источники обращений.

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

Для выявления SMS-бомбинга важно оценивать распределение обращений и совокупность доступных признаков. Ограничение подозрительных запросов до SMS-шлюза помогает снизить расходы и нагрузку.

Перед включением блокировки правило проверяют в режиме наблюдения. Критерий успеха — сокращение нежелательных отправок при сохранении нормального получения кодов клиентами.

2. Найти действующий аккаунт по украденным данным

При credential stuffing атакующий использует готовые пары логин — пароль, полученные в результате компрометации. Он проверяет их на других ресурсах в расчете на повторное использование паролей.

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

Задача входного контроля — выявить автоматизацию и ограничить подозрительные обращения до обработки сервисом авторизации.

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

3. Проверить чужую карту через платежную форму

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

Такие обращения не обязательно содержат признаки эксплуатации уязвимости. Они используют предусмотренный интерфейс оплаты, поэтому корректность полей сама по себе не подтверждает легитимность действий.

Анализ характера запросов, их последовательности и доступного контекста помогает выявлять автоматизированное тестирование. Preventive Proxy ограничивает подозрительную активность до прикладной обработки. Риск самих платежей оценивается средствами транзакционного контроля.

4. Забрать бонусы через массовые регистрации

Акция для новых клиентов может привлечь скрипты, которые создают множество профилей ради приветственных предложений. Для бизнеса это означает расходование бюджета на аккаунты, за которыми не стоят новые покупатели.

Условный пример. После запуска промокода сервис фиксирует рост регистраций. Но ожидаемого увеличения повторных покупок нет. Проверка показывает: часть профилей создается автоматически для получения скидки. Форма принимает корректные данные, а статистика привлечения растет за счет фиктивных аккаунтов.

Такой фрод в e-commerce требует контроля до создания учетной записи. Полезны признаки автоматизации и связи между обращениями, которые можно установить по доступным данным.

Дальнейшее использование бонусов — отдельная задача. Для нее необходимы проверки действий в сессии и операций программы лояльности.

Как работает анализ в Preventive Proxy

Решение опирается на совокупность признаков. IP-адрес, частота или отдельный заголовок не всегда позволяют уверенно отличить пользователя от вредоносного скрипта.

В зависимости от подключения для анализа доступны параметры HTTP-запросов и сетевой контекст. Интеграция через Web Snippet или SDK дополняет их характеристиками устройства и взаимодействия с приложением.

Источники данных важно различать. Движения мыши и скорость ввода не появляются в серверном API-запросе автоматически: для такой телеметрии требуется соответствующая клиентская интеграция.

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

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

Как распределить контроль между уровнями защиты

Preventive Proxy можно включить в существующую цепочку обработки трафика вместе с CDN/WAF. Архитектуру выбирают исходя из каналов, необходимых данных и точек применения решений.

В веб-приложении клиентскую информацию передает Web Snippet, в мобильном — SDK. Для прямого API учитывают параметры обращений и другой контекст, доступный в выбранной схеме. Возможности такого подключения определяют при проектировании.

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

В линейке Fraud Protection задачи распределены между тремя продуктами:

• Preventive Proxy контролирует вредоносные автоматизированные обращения до бизнес-логики.
• Session Fraud Protection анализирует риски при входе и в ходе цифровой сессии.
• Transaction Fraud Protection оценивает транзакции и другие критичные операции.

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

Проверка на практике

Выберите один из описанных сценариев и воспроизведите его в согласованном тестовом контуре. Затем измените условия: распределите обращения между источниками, добавьте паузы и сохраните частоту каждого источника в допустимых пределах.

Оцените результат:

• Сохранилось ли выявление подозрительной активности?
• Какие признаки повлияли на решение?
• Достаточно ли данных устройства и сессии?
• Где применяется ограничение?
• Успевает ли оно предотвратить нежелательную отправку, регистрацию или другую обработку?
• Как правило влияет на легитимные действия?

Проверка покажет, какие сценарии покрывает текущая конфигурация и где нужны дополнительные данные или меры контроля.

Подробнее — в White Paper о Preventive Proxy

В материале «Остановите ботов, пока они не остановили ваш бизнес» рассмотрены скрейпинг, credential stuffing, кардинг, злоупотребление бонусами и SMS-бомбинг.

Внутри — сравнение подходов к защите, описание архитектуры Preventive Proxy и результаты пилотного проекта.

Заполните форму, чтобы получить White Paper на почту →