Honeypot и невидимая капча: как работают ловушки для ботов в формах

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

Есть альтернативы, которые работают незаметно для человека: honeypot-ловушки, невидимая капча и поведенческий анализ. Разберёмся, как работает капча в её современных версиях, как устроена ловушка для ботов своими руками — с рабочим примером кода — и где границы каждого метода. Поймём, почему против современных ботнетов одного honeypot уже мало и какие фильтры стоит ставить поверх него.

Зачем нужна проверка на робота и почему классическая капча убивает конверсию

Проверка на робота существует потому, что спам-скрипты проходят по формам автоматически: парсят HTML, находят endpoint'ы, шлют POST-запросы напрямую, минуя отрисованную страницу. Одна незащищённая форма на популярном домене собирает от 15 до 40% мусорных заявок, а в момент залповых атак — сотни отправок в час с мусорными и чужими номерами. Классификация этого мусора и его цена для отдела продаж — в статье о фейковых заявках, здесь же важно другое: без фильтрации заявки приходят бесконечным потоком, и отличить в CRM бота от клиента по внешнему виду невозможно.

Капча решает задачу, но создаёт новую. Цифры потерь от классической капчи известны давно: по данным исследований рынка, она снижает конверсию форм в среднем на 10–20%, а на мобильных устройствах — до 25–30%, потому что решать визуальные задачи на маленьком экране неудобно, а трафик сегодня преимущественно мобильный. Отдельные категории посетителей страдают сильнее: пользователи с ослабленным зрением, посетители через VPN и приватный режим, аудитория 55+ — именно те, кто в B2B-сегменте часто является лицом, принимающим решение. Итог: защищая форму от ботов, капча одновременно отсекает часть реальных клиентов и обходится бизнесу дороже, чем кажется.

Сравните сами на своих цифрах. Форма без капчи конвертирует, условно, 8% посетителей в заявку. Поставили капчу — конверсия упала до 6,5%, и часть из оставшихся — это люди, которые решили задачу со второй или третьей попытки, уже раздражённые. Теперь посчитайте стоимость: при 5 000 посетителей в месяц вы теряете 75 заявок, из которых по конверсии в сделку 10% — семь сделок. При среднем чеке 100 000 ₽ это 700 000 ₽ выручки, отданные за защиту от ботов, которых могло бы не быть вовсе — достаточно вспомнить, что доля автоматического спама обычно 15–40%, а не 100%: остальные заявки приносят живые клиенты, и именно их капча травмирует первой.

Есть и вторая проблема: капча не является непреодолимым барьером. Сервисы распознавания изображений пробивают её за копейки — от 0,5 до 2 ₽ за тысячу решённых задач, а современные скрипты умеют вызывать их API напрямую. Ботнет, который стоит атаке десятки тысяч рублей, спокойно платит за распознавание. То есть классическая капча сегодня фильтрует в основном «случайных» спамеров и часть живых клиентов, а организованный фрод проходит почти без потерь. Подробно экономика фрода и почему он выгоден атакующим — в статье о скликивании в Яндекс Директе.

Как работает капча: от картинок к скоринг-поведению

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

Историческая справка полезна, чтобы понять, почему всё сложилось именно так. Изначально капча — это тест Тьюринга в обратную сторону: задача, простая для человека и трудная для машины. В 2000-х искажённого текста хватало: OCR-системы того времени пробивали его с трудом. Затем пошла гонка: нейросети научились читать даже сильно искажённые символы с точностью выше человеческой, и задачи пришлось усложнять — до знаменитых светофоров и гидрантов. Стоимость решения для атакующего при этом падала год от года: сегодня распознавание картинки обходится в доли копейки, а фермы живых разметчиков решают любые визуальные задачи оптом. Тест Тьюринга, рассчитанный на то, что машина «не справится», превратился в рутинную статью расходов спамера — поэтому индустрия и перешла от «проверять всех задачей» к «оценивать всех скорингом».

Второе поколение — интерактивный чекбокс («я не робот») с анализом движения мыши. Здесь проверяется уже не зрение, а поведение: как курсор подходит к галочке, ровно ли движение, есть ли микродрожание живой руки. Боты отвечали эмуляцией движений, капча усложняла проверку — гонка продолжается до сих пор и в чистом виде решает мало что.

Промежуточная стадия второго поколения — картинки-пазлы: «выберите все фрагменты с пешеходными переходами». Для человека это секунды, для бота — отдельная задача компьютерного зрения, которая тоже решена: готовые модели определяют нужные объекты на фрагментах с точностью 95%+. С точки зрения UX это самая раздражающая версия капчи: при медленном соединении картинки подгружаются по одной, и посетитель вынужден ждать, прежде чем вообще начать решать. Каждая такая секунда ожидания — проценты конверсии, уходящие в никуда.

Третье поколение — скоринг без каких-либо действий пользователя. Сервис собирает десятки сигналов: историю браузера и cookies, отпечаток устройства, время загрузки страницы, паттерны движения, соответствие IP реальному провайдеру, наличие автоматизации в окружении. По совокупности каждому посетителю присваивается оценка «вероятность бота», и только низкий скоринг вызывает дополнительную проверку. Для большинства живых людей капча третьего поколения невидима: форма просто работает.

Полезно понимать и внутреннее устройство скоринга, потому что от него зависят его слабые места. Модель обучается на миллиардах взаимодействий, и её главный корм — контрасты: чем больше известно о «нормальном» поведении, тем точнее детект. Но точность никогда не бывает стопроцентной: новое устройство без истории, свежий браузер, корпоративный прокси — всё это выглядит «как бот» для модели, хотя за ними живой человек. Поэтому скоринг всегда допускает регулировку порога: агрессивный режим ловит больше ботов и больше мучает пограничную аудиторию, мягкий — наоборот. Поставщики антиботов калибруют порог под средний сайт, а ваш B2B-ландинг с узкой аудиторией в него может не попадать.

Именно этот принцип — «проверять всех, беспокоить подозрительных» — лёг в основу невидимой капчи и поведенческого анализа, которые используются в защите форм. Но и у скоринга есть границы: часть живых посетителей с нестандартной конфигурацией регулярно получает низкие оценки и всё-таки решает задачи. Доля таких «ложных подозрительных» — обычно 2–8% от всех посетителей, и в часы пиковой нагрузки она растёт. Для формы заявки, где посетитель уже готов оставить номер, эти 2–8% — это прямые потери: человек уходит на страницу конкурента, а не разгадывает картинки.

Honeypot: ловушка для ботов своими руками

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

Метод старше, чем кажется: honeypot-системы использовались в информационной безопасности с 1990-х — тогда это были целые серверы-приманки, на которых ловили атакующих и изучали их методы. В веб-формах идея сжалась до одного скрытого поля, но логика прежняя: дай автоматике то, чего она не умеет игнорировать, и используй её же предсказуемость против неё. Спамер не может заранее знать, какие поля у формы «настоящие», поэтому вынужден либо рисковать, либо анализировать страницу — а анализ страницы дороже простой отправки.

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

Название поля выбирают нейтральное — «company_site», «website», «phone_confirm» — чтобы оно выглядело естественно для парсера и не отпугивало разработчика бота. Проверку делают на сервере, а не в JavaScript: скрипт-спамер может не исполнять JS вообще, и клиентская проверка его не увидит. Готовая реализация с правильными именами полей и серверной валидацией — в скрипте защиты форм для HTML-сайта: там honeypot уже встроен и не требует ручной настройки.

Для популярных CMS есть нюансы. В WordPress honeypot-поле добавляется фильтром к стандартным формам — без установки капча-плагина, который тянет за собой внешние сервисы и замедляет страницу: honeypot для WordPress без плагина-капчи — в инструкции по платформе. На Tilda и Bitrix24 поле добавляется в конструкторе формы и обрабатывается на стороне виджета защиты. Во всех случаях принцип одинаков: скрытое поле заполнено — заявка отклоняется до записи в CRM.

Три ошибки встречаются в реализациях чаще всего. Первая — проверка только на клиенте: скрипт на JavaScript скрывает форму от «плохих», но спамер шлёт запросы напрямую на endpoint и никакой клиентский код не исполняет; решение — серверная проверка обязательна. Вторая — одинаковые имена полей у всех: если ваше поле называется «honeypot» или «trap», бот-разработчик добавит его в исключения за один вечер; имя должно быть нейтральным и уникальным для сайта. Третья — блокировка по самому факту заполнения без анализа значения: редкий, но реальный случай — автозаполнение браузера вписало в скрытое поле адрес сайта из профиля пользователя; правильная проверка смотрит, что поле заполнено, и относит такую заявку на ручной разбор, а не в мусор мгновенно.

Отдельно — про время: honeypot не замедляет страницу. Это важное отличие от сторонних капч-сервисов, которые грузят скрипты с внешних доменов, добавляют запросы и ухудшают показатели скорости — а скорость напрямую влияет на конверсию и на оценку сайта поисковиками. Honeypot — это пара строк HTML и одна проверка на сервере: нулевая нагрузка, нулевые внешние зависимости, нулевой эффект на SEO. По этой причине его рекомендуют как первый слой защиты даже там, где поверх планируются более сложные фильтры.

Доступность — обязательный пункт чек-листа. Скрывать поле нужно не только визуально: у него должны быть атрибуты aria-hidden="true" и tabindex="-1", а в лейбле — прямой текст «не заполняйте это поле». Иначе пользователь скринридера услышит лишнее поле и может заполнить его по привычке, после чего его честная заявка уйдёт в корзину. Honeypot, который ловит людей с ограниченными возможностями, хуже отсутствия защиты.

Сравним три основных подхода к невидимой проверке, чтобы было от чего оттолкнуться при выборе.

Вывод из таблицы простой: методы не конкурируют, а дополняют друг друга. Honeypot закрывает самый дешёвый мусор бесплатно, невидимая капча добивает эмуляторы, а верификация номера отвечает на последний вопрос: «номер настоящий и принадлежит заявителю?» На него не может ответить ни одна поведенческая система — код приходит на SIM-карту, которой у бота нет.

Невидимая капча и behavioral-анализ: где границы метода

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

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

Границы метода тоже нужно знать честно. Первое: поведенческий анализ требует, чтобы скрипт исполнялся в браузере посетителя — прямые POST-запросы к endpoint'у формы он не увидит, и там нужен серверный фильтр. Второе: профиль поведения собирает данные о посетителях, а это вопрос прозрачности — в политике конфиденциальности сайта стоит упомянуть антифрод-обработку. Третье: метрики могут лагать на очень медленных устройствах и плохих соединениях, где события приходят рывками; хороший фильтр учитывает это и не блокирует по одному сигналу. Четвёртое: прокси и корпоративные сети делают поведение «серым» — автоматизация, ровный ритм, чужой IP — и доля ложных срабатываний растёт именно там, где сидят B2B-клиенты. Поэтому поведенческий фильтр всегда работает в связке с другими уровнями, а не в одиночку.

Практический список сигналов, которые собирает поведенческий фильтр на лид-форме: время от загрузки страницы до первого взаимодействия; время заполнения каждого поля; количество исправлений и возвратов курсора; порядок фокуса полей — совпадает ли с визуальным; события скролла и движения мыши до формы; соотношение времени на странице и времени на форме; скорость набора текста по символам в секунду. По каждому сигналу строится оценка, и типичный порог фильтрации — не одно событие, а связка: «форма заполнена за 3 секунды + ноль исправлений + фокус сразу в последнем поле» — это профиль скрипта с вероятностью, близкой к 100%. Живой человек так не заполняет никогда.

Важно не перегнуть палку: агрессивный поведенческий фильтр с низким порогом начинает ловить торопливых клиентов, которые реально хотят оставить заявку за десять секунд — они уже знают, что напишут, потому что второй раз на сайте. Такие заявки не должны блокироваться, а маршрутизироваться: например, отправляться в CRM с пометкой «ускоренное заполнение — проверить номер вручную» или проходить усиленную верификацию. Принцип тот же, что и у хорошей капчи третьего поколения: фильтруем автоматику, но не наказываем за скорость живого.

Почему одного honeypot мало против современных ботнетов

Классический honeypot рассчитан на примитивных ботов, которые перебирают поля наугад. Современные скрипты умнее: они анализируют CSS перед отправкой, видят display:none и position:absolute с отрицательными координатами, и пропускают скрытые поля. Боты на headless-браузерах вообще исполняют страницу как настоящий Chrome — включая отрисовку, куки и события. Против них ловушка из одного поля не срабатывает.

Спамеры также диверсифицируют запросы: часть ботов заполняет honeypot-поле, часть — нет, и фильтр по одному признаку либо пропускает половину мусора, либо начинает ловить чистую воду. Плюс появились атаки с ручным трудом: дешёвые разметчики проходят форму как люди, включая капчу и honeypot. Полностью закрыть такой поток на уровне поведения нельзя — здесь нужна проверка факта владения контактом.

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

• Honeypot — дешёвый базовый слой против примитивных скриптов: отсеивает 30–50% автоматического спама.
• Поведенческий анализ — против headless-браузеров и эмуляторов: смотрит на ритм и паттерны, а не на поля.
• Верификация номера — против всего, что прошло первые слои: flash call или SMS с кодом подтверждают, что номер принадлежит живому клиенту. Способы и цены — в статье о верификации телефона для сайта, базовая терминология — в материале о том, что такое верификация.
• Rate-limiting — против залпов: ограничение числа отправок с одного IP и устройства ломает перебор баз.

Почему нельзя остановиться на первом слое, видно из экономики атакующего. Сбор форм — тиражируемый бизнес: один скрипт обходит тысячи сайтов, и стоимость адаптации под ваш конкретный фильтр — вечер работы программиста. Если ваш сайт защищён только honeypot, а у соседнего — ничего, спамер пройдёт к соседу; но если ваш домен ценен — реклама дорогая, ниша конкурентная — адаптация под вас окупится. Поэтому критерий выбора защиты не «какой фильтр самый сильный», а «сколько слоёв нужно, чтобы стоимость обхода превысила выгоду атаки». Обычно хватает двух-трёх слоёв: базового поведенческого, фильтра залпов и верификации номера.

Есть и атаки, против которых поведенческие методы бессильны по определению: ручное заполнение форм людьми за небольшую плату. Такие «фермы» решают капчи, обходят honeypot, ведут себя на странице как нормальные посетители — потому что это и есть нормальные посетители, только чужие. Единственный фильтр против них — подтверждение владения контактом: код из flash-звонка или SMS приходит на SIM-карту настоящего владельца номера, а у исполнителя фермы её нет. Это принципиальное отличие: поведенческие системы отвечают на вопрос «кто заполняет», верификация — на вопрос «кому принадлежит номер». Для лид-генерации, где ценность заявки определяется возможностью дозвониться, второй вопрос важнее.

Сравнение классов решений — WAF, капча, виджет для форм — и матрица «что выбрать под свою ситуацию» — в статье об антибот-системах для сайта. Если собирать контур самому не хочется, все перечисленные слои уже собраны в готовый виджет защиты форм от ботов: honeypot, поведенческий фильтр и каскадная верификация номера работают из коробки, подключаются 2 строками кода, а первые 5 проверок каждый месяц бесплатны. Тарифы — подписка за пакет: «Старт» 1 690 ₽/мес за 30 проверок, «Про» 3 990 ₽/100, «Бизнес» 8 990 ₽/300; flash call как основной канал подтверждения — в 2–3 раза дешевле SMS, а если оператор заблокировал звонок, автоматически уходит SMS, чтобы лид не потерялся.

Реалистичные ожидания от такого пирога: автоматический мусор уходит полностью, ручной фрод с чужими номерами ловится верификацией, а доля недозвонов по оставшимся заявкам обычно падает с 25–35% до 3–7%. Про потери от мусорных заявок подробно — в статье о некачественных лидах: там же воронка фильтрации от клика до CRM и расчёт стоимости мусора для отдела продаж.

И последнее практическое замечание: любую защиту формы стоит проверять на реальных данных, а не на обещаниях вендора. Контрольный срок — две недели после внедрения: сравните долю недозвонов, число заявок и конверсию в сделку с базовым периодом. Если автоматический мусор продолжает проходить — фильтр настроен мягко или боты адаптировались; если растут жалобы живых клиентов — порог слишком жёсткий. Рабочая защита держится посередине: мусор уходит, люди не замечают ничего.

Частые вопросы