Как остановить спам с форм сайта и фальшивые заявки
Спам через формы сайта — одна из самых неприятных разновидностей автоматизированного трафика. Он не всегда выглядит как классическая атака: сайт продолжает работать, страницы открываются, но в почту, CRM или личный кабинет начинают поступать десятки и сотни бесполезных обращений. Среди них могут быть бессмысленные сообщения, рекламные тексты, ссылки, одинаковые заявки, фиктивные контакты и формы, отправленные без участия реального человека.
Проблема особенно болезненна для коммерческих сайтов. Фальшивые заявки загрязняют CRM, мешают менеджерам быстро обрабатывать настоящих клиентов, искажают аналитику конверсий и могут увеличивать нагрузку на почтовую инфраструктуру. Если сайт передаёт каждую форму в несколько внешних сервисов, один автоматизированный запрос способен запускать целую цепочку действий.
Простая CAPTCHA иногда уменьшает поток, но редко решает задачу полностью. Современные автоматизированные браузеры умеют выполнять JavaScript, получать cookies, заполнять поля и повторять обычную последовательность отправки формы. Поэтому надёжная защита строится на нескольких уровнях: проверке поведения, ограничении частоты, серверной валидации, фильтрации на уровне WAF и контроле того, какие запросы вообще допускаются к обработчику формы.
Важно: форма должна считаться защищённой не тогда, когда спам перестал попадать в почту, а когда нежелательные автоматизированные запросы перестали успешно проходить весь сценарий отправки.
Откуда берётся спам с форм
Источники могут быть разными. Иногда это массовые спам-боты, которые автоматически находят формы на тысячах сайтов. В других случаях атака направлена на конкретный проект: бот многократно отправляет заявки, создаёт нагрузку или мешает работе отдела продаж.
- массовые рекламные боты;
- автоматизированные браузеры;
- скрипты, напрямую обращающиеся к обработчику формы;
- боты, работающие через прокси и меняющие IP;
- сценарии, имитирующие реальные лиды;
- автоматическая генерация форм с фиктивными телефонами и email;
- повторные отправки одного и того же содержимого.
Почему фальшивые заявки опаснее обычного спама
Обычный спам часто легко узнаётся: рекламный текст, набор ссылок или бессмысленные символы. Фальшивая заявка может выглядеть правдоподобно. В ней есть имя, телефон, выбранная услуга и комментарий. Менеджер тратит время на проверку, звонок и повторную попытку связаться.
Если таких заявок много, они начинают влиять на бизнес-процессы: растёт число «лидов», падает фактическая конверсия в продажу, отчёты становятся менее полезными, а сотрудники теряют время на несуществующих клиентов.
Фальшивая заявка — это не только мусор в форме. Она может искажать маркетинговые показатели, нагружать CRM и создавать дополнительные расходы на обработку.
Как бот обычно отправляет форму
Самый простой сценарий — прямой HTTP-запрос к обработчику формы. Боту даже не обязательно загружать страницу в браузере. Если endpoint принимает данные без дополнительных проверок, автоматизация может отправлять их напрямую.
Более сложный бот сначала открывает страницу, получает cookies, выполняет JavaScript, находит поля формы и отправляет данные так же, как обычный браузер. Такой трафик труднее отличить от человека, особенно если каждая сессия идёт с нового IP и с немного отличающимися параметрами.
Почему одной CAPTCHA часто недостаточно
CAPTCHA остаётся полезным дополнительным уровнем, но её эффективность зависит от сценария. Простая проверка может остановить примитивный скрипт, однако браузерная автоматизация способна пройти часть подобных механизмов или использовать внешние сервисы распознавания.
Кроме того, постоянная CAPTCHA для всех посетителей ухудшает пользовательский опыт. Реальные клиенты вынуждены выполнять лишнее действие, а автоматизированный трафик иногда всё равно проходит. Поэтому лучше использовать многоуровневую схему, где CAPTCHA включается только для подозрительных сессий.
Скрытое поле honeypot
Honeypot — это поле, которое обычный пользователь не видит и не должен заполнять. Простой бот, автоматически заполняющий все поля формы, может записать туда значение и тем самым выдать себя.
Метод полезен против массовых универсальных спамеров, но не является универсальным. Современный бот способен анализировать HTML, CSS и поведение формы. Поэтому honeypot лучше использовать как дополнительный сигнал, а не как единственную защиту.
Проверка времени заполнения формы
Человек не может открыть страницу и заполнить сложную форму за доли секунды. Если отправка происходит практически сразу после получения страницы, это весомый признак автоматизации.
Но и здесь нельзя использовать слишком жёсткое правило. Пользователь может использовать автозаполнение браузера, а бот — специально подождать несколько секунд. Временная проверка полезна только вместе с другими сигналами.
Ограничение частоты отправок
Rate limiting позволяет ограничить количество обращений к обработчику формы за определённый период. Это хорошо работает против агрессивного спама, когда один клиент отправляет десятки заявок подряд.
Но жёсткий лимит только по IP может ошибаться. За корпоративным прокси или мобильным NAT могут находиться разные реальные люди, а распределённый бот способен менять адреса. Поэтому ограничения лучше учитывать вместе с cookies, браузерными признаками и структурой запросов.
Серверная валидация обязательна
Любая форма должна проверяться на сервере. Проверки только в JavaScript помогают пользователю, но не защищают обработчик: автоматизированный клиент может отправить HTTP-запрос напрямую, минуя браузерный интерфейс.
- обязательность нужных полей;
- разумная длина значений;
- допустимый формат телефона и email;
- отсутствие неожиданных полей;
- проверка идентификаторов и токенов;
- контроль происхождения запроса;
- защита от повторной отправки одного и того же события.
CSRF-токен и одноразовые идентификаторы
Одноразовый токен связывает отправку формы с ранее открытой страницей или пользовательской сессией. Это усложняет прямые обращения к endpoint без предварительного прохождения нормального сценария.
Однако токен не является антиботом сам по себе. Если автоматизированный браузер открывает страницу, получает токен и затем корректно отправляет форму, такая проверка будет пройдена. Поэтому токены защищают целостность сценария, но не заменяют анализ автоматизации.
Повторяющиеся заявки — отдельный сигнал
Автоматизация часто генерирует похожие сообщения: одинаковые шаблоны текста, повторяющиеся номера, одинаковую длину комментария или последовательность значений. Даже если IP меняется, содержимое заявок способно выдать общий источник.
Полезно фиксировать не только отдельные заявки, но и повторяемость признаков за период. Это позволяет обнаружить распределённую автоматизацию, которую трудно увидеть по одному адресу.
Почему спам может идти с множества IP
Современные боты используют прокси, мобильные сети и распределённую инфраструктуру. Поэтому каждая новая заявка может приходить с нового адреса. Простая IP-блокировка в такой ситуации малоэффективна.
Более устойчивый подход — анализировать совокупность: сеть, ASN, cookies, браузерные признаки, частоту, маршрут до формы и структуру самой отправки.
Если IP постоянно меняется, ищите не адрес, а повторяющийся сценарий. У распределённого бота часто остаются общие признаки на уровне HTTP, браузера или поведения.
Как спам влияет на Яндекс Метрику
Если бот работает через браузер и выполняет код счётчика, его визиты могут попадать в Метрику. Тогда фальшивые отправки формы способны увеличивать количество достижений целей и создавать впечатление роста конверсии.
При этом CRM или почта показывают другое качество обращений. Это один из характерных сигналов: аналитика фиксирует рост заявок, а реальные продажи и нормальные контакты не растут.
Сопоставляйте Метрику, CRM и server logs
| Источник | Что показывает |
|---|---|
| Яндекс Метрика | Визиты, цели, источники и поведение сессий. |
| CRM | Фактические лиды, статусы и качество обращений. |
| Почта | Какие сообщения реально отправляет сайт. |
| Access-лог | Фактические HTTP-запросы к форме и endpoint. |
| WAF / reverse proxy | Какие запросы были пропущены, ограничены или заблокированы. |
Чем сильнее расходятся эти уровни, тем важнее техническая проверка. Например, если Метрика показывает сотню целей, а CRM получает несколько нормальных лидов и десятки мусорных записей, проблема уже не только аналитическая.
Как защитить AJAX-формы и API
Современные формы часто отправляются через AJAX или REST API. Это удобно для пользователя, но делает endpoint самостоятельной точкой входа. Его необходимо защищать так же, как обычную страницу формы.
- проверять обязательные параметры на сервере;
- не доверять данным только потому, что они пришли из JavaScript;
- ограничивать частоту запросов;
- проверять токены и cookies;
- отсекать очевидно некорректные структуры;
- логировать причины отказов.
Почему нельзя блокировать всех по одному признаку
Настоящий пользователь может отправить две заявки подряд, использовать VPN, открыть сайт без Referer или работать через корпоративный прокси. Поэтому любое слишком широкое правило создаёт риск потери реального клиента.
Хорошая защита должна быть ступенчатой: явно доверенный трафик проходит без препятствий, явно автоматизированный блокируется, а спорные сессии получают дополнительную проверку.
Как CRONARMOR фильтрует спам с форм
CRONARMOR анализирует запросы до передачи на основной сервер сайта. Это позволяет остановить часть автоматизированных отправок ещё до запуска CMS, обработчика формы, почтового модуля и CRM-интеграции.
- сетевые признаки и ASN;
- частота обращений к форме;
- HTTP-характеристики запроса;
- cookies и браузерные проверки;
- повторяемость сессий;
- аномальные маршруты к endpoint;
- индивидуальные правила конкретной формы;
- доверенный пропуск реальных интеграций.
Особенно важно не ломать рабочие сценарии: формы обратного звонка, корзину, AJAX, API мобильного приложения, CRM-webhook-и и другие легитимные обращения. Поэтому правила должны настраиваться под фактическую архитектуру сайта.
Цель защиты — не просто скрыть спам из почты. Нужно остановить нежелательный запрос раньше, чем он создаст заявку, событие аналитики, запись в CRM и дополнительную нагрузку на инфраструктуру.
Практический чек-лист для владельца сайта
- Определить, через какие формы приходит основной спам.
- Проверить, можно ли обратиться к обработчику напрямую.
- Убедиться, что вся валидация выполняется на сервере.
- Добавить защиту от слишком частых отправок.
- Использовать honeypot и временные проверки как дополнительные сигналы.
- Включить логирование запросов к форме.
- Сопоставить цели Метрики с реальными заявками в CRM.
- Не применять CAPTCHA ко всем посетителям без необходимости.
- Фильтровать нежелательные запросы до CMS через WAF или reverse proxy.
FAQ
Почему спам проходит через CAPTCHA?
Потому что современные автоматизированные браузеры умеют выполнять JavaScript и проходить часть проверок. CAPTCHA лучше использовать как один из уровней, а не как единственную защиту.
Поможет ли блокировка IP?
Против простого источника — да. Но распределённые боты меняют IP, а широкая блокировка может задеть реальных пользователей.
Можно ли просто убрать цель из Метрики?
Это лишь изменит отчёт. Фальшивая форма продолжит отправляться на сайт, в почту или CRM.
Нужно ли защищать AJAX-форму отдельно?
Да. AJAX- или API-endpoint является самостоятельной точкой отправки данных и должен проходить серверную проверку и защиту.
Какая схема наиболее эффективна?
Сочетание серверной валидации, ограничения частоты, поведенческих сигналов, токенов, логирования и внешней фильтрации подозрительных запросов.
Нужно остановить спам и фальшивые заявки?
CRONARMOR фильтрует нежелательные автоматизированные запросы на внешнем защитном контуре до передачи на основной сервер, помогая снизить спам в формах, нагрузку на сайт и количество фиктивных обращений.