Защита от ботов

Защита от ботов для сайта начинается не с блокировки, а с классификации трафика

Главная ошибка, которую мы регулярно видим на практике, проста: весь автоматизированный трафик пытаются записать во “вредоносный”. Это удобно только на бумаге. В реальности автоматизация бывает разной. Есть поисковые и рекламные роботы, технические fetcher-сервисы, мониторинг, интеграции партнеров, внутренние скрипты, мобильные приложения, проверки доступности и нормальные фоновые обращения. Google прямо разделяет свои запросы на common crawlers, special-case crawlers и user-triggered fetchers. Обычный Googlebot подчиняется robots.txt, часть специальных роботов действует по договоренной логике, а некоторые пользовательские fetcher-запросы вообще игнорируют robots.txt, потому что инициируются действием пользователя. Из этого следует практический вывод: защита от ботов не должна “рубить все, что не похоже на человека”. Она должна отделять полезные сервисы от вредоносных сценариев и особенно внимательно относиться к тем, кто лишь выдает себя за Googlebot, AdsBot или другой доверенный сервис.

Этот момент важен и для поиска, и для доступности, и для обработки контента. Google отдельно предупреждает: если вы хотите остановить именно индексирование, одного запрета в robots.txt недостаточно, нужен noindex на доступной для краулера странице. Параллельно Google рекомендует проверять реальные запросы от Googlebot по reverse DNS и IP-диапазонам, потому что user-agent подделывают регулярно. Для нас это не теоретическая ремарка, а часть ежедневной настройки: защита от ботов должна пропускать верифицированные поисковые обращения, не ломать индексацию полезных разделов сайта и при этом отсекать фальшивые “поисковые” запросы, за которыми прячется скрейпинг, спам или массовый перебор.

• Полезные боты нужны бизнесу: они помогают поиску, проверке доступности и интеграциям сервисов.
• Неверифицированные боты опасны тем, что выглядят правдоподобно и часто маскируются под обычный браузер, поисковый crawler или мобильное приложение.
• Нормальная защита начинается с allowlist-политики, верификации и анализа поведения, а не с тотального deny для всего “нечеловеческого”.

Почему защита от ботов перестала быть нишевой задачей

Последние публичные цифры показывают, что проблема давно вышла за рамки отдельных отраслей. В релизе Thales от 15 апреля 2025 года по итогам 2024 года указано, что автоматизированный трафик впервые за десятилетие обогнал человеческий и занял 51% всего web-трафика. Из него 37% пришлось на bad bots. Годом ранее Thales сообщала, что в 2023 году боты уже генерировали 49,6% всего интернет-трафика, а доля вредоносных ботов выросла до 32%. Это важная динамика: речь не про единичный всплеск и не про историю “у крупных компаний так, а у нас нет”. Автоматизация стала нормальной средой для интернета, и вопрос теперь не в том, встречаются ли боты на вашем сайте, а в том, какие именно боты у вас уже работают и что именно они делают.

Cloudflare в своем State of Application Security 2024 пишет, что в среднем боты составляют 31,2% всего application traffic, проходящего через их сеть, а 93% выявленных ботов являются unverified bots, то есть не подтвержденными как доверенные. Это тоже важный срез. Даже там, где компания не ощущает явного фрода, бот-трафик присутствует постоянно и часто остается в серой зоне: его не видят как отдельную проблему, пока не начинает проседать конверсия, дорожать инфраструктура, ломаться аналитика или приходят жалобы от пользователей.

OWASP рассматривает automated threats как самостоятельный класс угроз веб-приложениям не случайно. Автоматизированные сценарии не сводятся к одному типу атаки. Это и credential stuffing, и account takeover, и создание фейковых аккаунтов, и переполнение форм, и массовый парсинг контента, и abuse промокодов, и card testing, и спам, и злоупотребление поиском, и агрессивные запросы к API, и перегрузка приложения на уровне логики, когда номинально “легальные” запросы посылаются в таком объеме и с такой последовательностью, что ваш сервис начинает работать против самого себя.

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

Мы строим антибот-защиту как многослойную систему, потому что один признак сам по себе почти никогда не дает надежного ответа. Простая блокировка по IP давно не работает: трафик идет через residential proxy, мобильные сети, облачные узлы и распределенные пулы адресов. Проверка только по user-agent тем более бесполезна: современные боты умеют выдавать себя за Chrome, Mobile Safari и другие привычные браузеры. В отчете Imperva за 2025 год отдельно отмечено, что плохие боты активно имитируют популярные браузеры, а в 2024 году 46% таких атак маскировались под Chrome.

Поэтому рабочая защита от ботов всегда комбинирует несколько уровней анализа. Сначала идут эвристики: аномальные паттерны запросов, неестественные последовательности URL, скачки частоты, странные заголовки, сбои в порядке навигации, попытки обхода обычного пользовательского пути. Затем включается поведенческий анализ: как клиент двигается между страницами, какие интервалы между действиями, как ведет себя поиск, какие маршруты выбираются до авторизации и после нее. Дальше нужен анализ технических сигналов браузера и сети: headers, session characteristics, признаки headless-окружения, fingerprint, работа JavaScript, cookie, согласованность клиентской среды, IP reputation и сетевой контекст. И только поверх этого имеет смысл навешивать ML-модель, которая оценивает вероятность того, что перед нами человек, скрипт или гибридный сценарий.

Этот подход подтверждается и официальной технической документацией Cloudflare. У них бот-детект работает через несколько движков: heuristics, JavaScript detections, machine learning и anomaly detection. Легкий JS-модуль для HTML-страниц выполняется незаметно для пользователя, может работать в отдельном потоке, живет ограниченное время и записывает результат в служебный cookie. Важно, что такая проверка не применяется к API и mobile application traffic, потому что для API нужны другие сигналы и другая политика. После этого уже WAF-правила и challenge-механика решают, пропустить запрос, замедлить, ограничить rate limit, выдать проверку, потребовать captcha или полностью заблокировать.

Именно поэтому мы не рассматриваем captcha как универсальное решение. Captcha и challenge нужны, но как точечный инструмент. Если ставить их на каждый вход, вы разрушаете UX, портите конверсию, ломаете работу нормальных пользователей и часто не мешаете ботам, которые давно умеют обходить базовые проверки. Правильная логика другая: сначала тихий анализ, потом выборочная проверка, и только затем жесткая блокировка там, где риск действительно подтвержден. Для сайта это означает меньше трения для людей. Для бизнеса — меньше шума в аналитике и меньше потерь от ложных срабатываний.

Защита от ботов для API, личного кабинета и форм — это отдельный контур, а не приложение к фронтенду

Если коротко, API сегодня — одна из самых ценных точек атаки. Там лежит бизнес-логика, там происходят проверки доступа, там живут данные клиента, операции с балансом, заказами, остатками, статусами и персональными данными. В релизе Thales от 15 апреля 2025 года указано, что 44% advanced bad bot traffic уже нацелено на API. В релизе Thales от 16 апреля 2024 года по предыдущему периоду была похожая тревожная цифра: 44% всех account takeover атак пришлись на API endpoints, а 11% всех логинов в интернете были связаны с account takeover. Это означает, что форма входа на сайте и эндпоинт авторизации в API больше нельзя защищать разными по уровню зрелости решениями. Атакующий почти всегда идет туда, где слабее и тише контроль.

Дальше проблема становится финансовой, а не только технической. По исследованию Akamai API Security Impact Study, опубликованному в сентябре 2024 года, 84% опрошенных security-специалистов уже сталкивались с API security incident за последние 12 месяцев. Еще важнее другое: полную inventory своих API и понимание, какие из них обмениваются sensitive data, в 2024 году имели только 27% участников, хотя годом ранее таких было 40%. Средняя стоимость устранения API-инцидента в США составила 591 404 доллара, а в финансовом секторе — 832 801 доллар. Когда у компании нет нормальной карты API и четкого разделения между frontend, backend и внешними интеграциями, защита превращается в угадайку. Боты этим пользуются первыми.

Thales в отчете Economic Impact of API and Bot Attacks от 18 сентября 2024 года оценивает совокупные потери бизнеса от insecure APIs и bot attacks до 186 миллиардов долларов в год. Там же говорится, что крупные компании с выручкой более 1 миллиарда долларов в 2–3 раза чаще сталкиваются с автоматизированным API-abuse со стороны ботов, а среднее enterprise-окружение уже управляет примерно 613 API endpoints в production. То есть речь не о том, чтобы “закрыть пару проблемных методов”. Защита от ботов для API — это полноценная дисциплина: инвентаризация, приоритизация критичных операций, контроль авторизации, аномалий, сессий, частоты, business logic abuse и нетипичных последовательностей вызовов.

Отдельного внимания требуют формы логина, восстановления пароля, регистрации, контактные формы, заявки, поиск по сайту, оформление заказа, страницы наличия товара, расчет доставки, купоны, промокоды и любые публичные endpoints, которые можно прогреть автоматикой. Если у вас есть личный кабинет, онлайн-оплата, бонусная программа, каталог, API для приложений, поиск, корзина, обработка персональных данных или многократные проверки статусов, защита от ботов должна смотреть на эти маршруты не как на “страницы сайта”, а как на бизнес-операции с разной ценой ошибки.

Какие сценарии атак мы считаем приоритетными и почему одного WAF здесь мало

WAF нужен обязательно, но WAF сам по себе не равен антибот-системе. Он хорошо работает там, где видит правило, сигнатуру, известную последовательность или аномальный шаблон запроса. Но вредоносные боты часто используют формально валидные запросы: корректный путь, допустимый метод, нормальный JSON, правильные cookies и “чистый” JavaScript. Их отличие не в том, что запрос сломан, а в том, что цель вредоносна. Поэтому защита от ботов должна смотреть не только на содержимое запроса, но и на намерение, контекст и масштаб.

По материалам Imperva 2025 мы выделяем несколько сценариев, которые почти всегда бьют по деньгам или репутации. Первый — credential stuffing и account takeover. Финансовый сектор в 2024 году стал главным получателем ATO-атак, забрав 22% всех инцидентов такого типа. Это логично: там высокая стоимость аккаунта, платежные данные, PII, быстрый путь к монетизации и чувствительность к времени реакции. Второй — price scraping и content scraping. Для e-commerce, travel, маркетплейсов, медиа, блогов, агрегаторов и онлайн-сервисов это прямой ущерб: конкуренты быстрее реагируют на цены, данные уходят в чужие базы, а агрессивные скрейперы могут замедлять сайт почти так же заметно, как небольшая DDoS-атака.

Третий сценарий — inventory abuse. В travel это seat spinning, в retail — scalping и удержание остатков, в event и ticketing — выкуп или резерв без намерения завершить покупку. По данным Thales/Imperva, travel в 2024 году вышел на первое место по объему бот-атак и занял 27% всех bot attacks, обогнав retail. Для авиакомпаний, отелей, доставки, ритейла и маркетплейсов это не абстрактная “нагрузка”, а искажение доступности товара, ложная картина спроса и прямой удар по выручке. Четвертый сценарий — ad fraud и analytics skewing. В отчетах Imperva они отдельно фигурируют для маркетинга, news, eCommerce и advertising environments. Если бот генерирует просмотры, клики, регистрации и событийную телеметрию, вы начинаете принимать решения по фальшивой аналитике: неверно перераспределяете бюджет, искажаете воронку, ухудшаете медиаплан и теряете время команды.

Cloudflare в State of Application Security 2024 отмечает, что DDoS остается самым распространенным типом атак на web applications, а за исследованный период компания блокировала или отправляла на challenge 6,8% всего application traffic. Для нас это означает простую вещь: защита от ботов и DDoS-защита должны работать вместе. На одних маршрутах нужен WAF, на других rate limiting, на третьих — behavioral engine, а на четвертых — гибкая challenge-логика. Только так можно закрыть одновременно и volumetric abuse, и медленный “умный” бот-трафик, который не пытается уронить сайт моментально, а спокойно высасывает деньги, данные и вычислительные ресурсы.

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

Для главной страницы и контентных разделов у защиты от ботов есть еще одна тонкая грань: если действовать грубо, можно навредить поиску сильнее, чем самому скрейпингу. Поисковые роботы, рекламные системы, валидаторы, безопасные user-triggered fetchers и ряд технических сервисов участвуют в нормальной работе веб-сайта. Google прямо говорит, что problematic request с user-agent Googlebot нужно сначала верифицировать, потому что этот user-agent часто подделывают. Поэтому мы не строим политику на строке “Googlebot” в заголовке запроса. Мы смотрим на reverse DNS, IP-диапазоны, сценарий обращения, частоту, маршрут и поведение.

Здесь же появляется история про контент. В Imperva 2025 среди последствий aggressive scraping отдельно перечисляются duplicate content, падение SEO rankings, необъяснимые slowdowns и downtime. Это знакомая проблема для медиа, каталогов, сервисов знаний, блогов, job boards, классифайдов и маркетплейсов. Если конкурент или серый агрегатор утягивает контент быстрее, чем его видит поиск, вы получаете не только лишние запросы к сайту, но и искажение цифрового следа вашего бренда. Поэтому защита от ботов для контента — это не борьба с роботами “вообще”, а контроль того, кто и в каком объеме может забирать страницы, изображения, карточки, сниппеты, цены, остатки, описания и другие данные.

Отдельно стоит сказать про JavaScript. Для современных сайтов на JS и SPA-приложений защита не должна мешать нормальному рендерингу страниц, но и не должна слепо доверять каждому клиенту, который исполнил минимум скриптов. Google Search Central отдельно напоминает, что краулеры по-своему обрабатывают JavaScript, а переиспользование одних и тех же ресурсов по стабильным URL помогает кэшированию и повторному использованию без лишних обращений. Значит, наша задача — не усложнить обход для поисковых систем, а убрать вредоносную автоматизацию вокруг контента, поиска по сайту и API, не ломая доступ к важным публичным ресурсам там, где он действительно нужен.

Когда защита от ботов уже нужна вашему бизнесу, даже если “ничего критичного пока не случилось”

Обычно бот-проблема не начинается с громкого инцидента. Сначала появляются косвенные симптомы. Растет число неуспешных логинов без видимой причины. В search-контурах увеличивается доля странных запросов, которые никто не может объяснить. Фронтенд и API периодически “подвисают”, хотя по CPU и памяти все выглядит терпимо. В аналитике начинают всплывать аномальные источники трафика и резкие всплески событий без конверсии. Каталог работает медленнее, карточки товаров открываются нормально не у всех пользователей, данные в рекламных кабинетах расходятся с фактами продаж, а поддержка получает жалобы на блокировки, пропавшие места, странные письма о входе или повторяющиеся challenge-проверки.

• Если на сайте есть форма входа, регистрация, личный кабинет или восстановление доступа, защита от ботов нужна до первого массового credential stuffing, а не после него.
• Если у вас есть API для мобильных приложений, партнеров или фронтенда, защиту стоит строить вокруг endpoints, а не только вокруг веб-страниц.
• Если проект живет за счет контента, цен, каталога, остатков, билетов, слотов, промокодов или рекламы, вам нужен контроль scraping, analytics skewing и abuse бизнес-логики.
• Если бизнес зависит от онлайн-доступности сервиса, нельзя отделять защиту от ботов от DDoS, rate limiting, WAF и общей системы приложений.

Часто нам говорят: “У нас нет банковского сервиса, значит, аккаунты не так важны”. На практике достаточно обычного кабинета клиента, чтобы бот нашел способ монетизации: перепродажа аккаунтов, кража бонусов, abuse скидок, тестирование похищенных карт на checkout-странице, накрутка заявок, отравление аналитики или сбор базы пользователей. Даже если прямой кражи денег нет, остается утечка времени команды, рост затрат на инфраструктуру, ошибочные продуктовые выводы и проблемы с персональными данными.

Защита от ботов в эксплуатации: что стоит проверить до запуска и после него

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

На этом этапе важно не только увидеть вредоносные запросы, но и решить, что именно нужно защитить в первую очередь. Для одного ресурса критична авторизация, для другого — выдача каталога, для третьего — обработка событий, промокодов, заказов и обращений. Бизнес-логика почти всегда отличается, поэтому антибот не должен жить отдельно от понимания самого сервиса. Он не заменяет все остальные меры и не защищает проект автоматически просто фактом установки. Его нужно использовать вместе с нормальной проверкой сессий, прав доступа, cookie, JavaScript, WAF и поведенческих правил.

Здесь особенно важен баланс между защитой и удобством. Иногда достаточно мягкой проверки с помощью JS и технических challenge-механик, иногда нужны rate limit и ручные правила, а иногда без жесткой блокировки не обойтись. Никаких универсальных рецептов тут нет. Более того, именно тем сигналам, которым безоговорочно доверяют самые простые фильтры, атакующие подражают быстрее всего. Поэтому защита от ботов работает лучше там, где система смотрит не на один параметр, а на контекст: как клиент ведет себя до логина, после логина и в какой момент начинает отклоняться от нормального пути пользователя.

Есть и менее очевидные зоны риска. Спам и abuse идут не только в логин, корзину или checkout, но и в формы “контакты”, “вакансии”, отзывы, поиск по сайту, служебные панели и партнерские разделы pro. Лишний трафик бьет не только по безопасности. Из-за него растут тарифы на облачные сервисы, обработку событий, CDN и хранение логов; искажается аналитика; приложение медленнее отвечает живым пользователям; а команде начинает казаться, что проблема находится в коде, хотя фактически сервис перегружен запросами ботами. Если это не заметить вовремя, защита от ботов потом внедряется уже в условиях аварийного реагирования, когда нужно не просто снизить шум, а быстро защитить доступность и убрать накопленный технический долг.

Что мы делаем после подключения защиты от ботов и почему это работает в реальной эксплуатации

Подключение защиты от ботов не должно превращаться в месяцы ручной охоты за каждым скриптом. Но и история “включили одну кнопку — и все готово” работает редко. Нормальная схема обычно выглядит так. Сначала мы собираем карту сервиса: какие маршруты дают прямой доступ к данным, какие endpoints критичны для авторизации, где находятся формы, где идет обработка персональных данных, какие разделы особенно чувствительны к парсингу контента, а какие — к искажению аналитики. Потом отделяем хорошие автоматизированные обращения: поисковые системы, рекламные краулеры, доверенные интеграции, технические сервисы. После этого настраиваем защиту по зонам риска: где-то нужны мягкие challenge-проверки и JS, где-то rate limit, где-то анализ cookie и сессий, где-то отдельные WAF-правила, а где-то — жесткая блокировка по признакам бизнес-abuse.

Дальше начинается самое важное: мониторинг после запуска. Любая защита без последующей калибровки либо недобирает вредоносный трафик, либо начинает мешать живым пользователям. Поэтому после подключения мы смотрим не только на количество блокировок. Нас интересует, как меняется доля подозрительных запросов, что происходит с конверсией, логинами, поиском, checkout, API, мобильным трафиком, временем ответа и жалобами пользователей. Если система просто “блокирует много”, это еще не успех. Успех — когда вредоносные боты перестают влиять на сайт, а обычные пользователи, поисковые роботы и легитимные сервисы продолжают работать без трения.

Именно в этом смысле защита от ботов — это не одиночный фильтр и не декоративный badge безопасности. Это операционная система контроля доступа к вашему ресурсу на уровне поведения. Она понимает разницу между пользователем и скриптом, между поиском и парсером, между нормальным API-клиентом и abuse-ботом, между реальным интересом к товару и автоматизированным удержанием остатков. Когда такая система настроена правильно, сайт работает быстрее и чище, аналитика становится честнее, а риск фрода, утечки данных и деградации сервиса уходит из “фоновой нормы” в управляемую зону.

Этот материал опирается на открытые данные Thales/Imperva, Cloudflare, Akamai, OWASP и Google Developer Documentation, опубликованные в 2024–2026 годах. Мы сознательно не пишем здесь рекламный текст и не обещаем невозможного: боты не исчезнут, но их можно последовательно выявлять, ограничивать и блокировать без разрушения работы сайта, приложений и API.