Спам через формы 1С-Битрикс: как защитить сайт и не потерять реальные заявки

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

Защиту форм на 1С-Битрикс стоит принимать по двум результатам: нежелательные отправки останавливаются, а клиент может обратиться с телефона, исправить ошибку и повторить попытку. Ниже — порядок проверки источника спама, выбор защитных мер и чек-лист приёмки. Примеры условные; они не описывают статистику конкретного магазина или клиентского проекта.

1. Установите, откуда приходит спам

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

• Есть запись заявки и обращение к обработчику сайта. Проверяйте конкретную форму и её серверную обработку. Это может быть форма в контактах, всплывающее окно или старый обработчик, на который уже нет видимой ссылки.
• Есть только письмо. Изучите служебные заголовки и почтовый журнал. Если сообщение доставлено прямо на ящик, установка капчи на сайте на этот путь не повлияет.
• Есть только лид в CRM. Проверьте источник создания: сайт, почтовый канал, виджет или интеграцию. Отсутствие локальной записи само по себе не исключает сайт — некоторые формы ничего не сохраняют в Битриксе.

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

2. Подберите защиту под поведение отправок

Для обычной формы полезно сочетать несколько проверок. Одной картинкой с кодом нельзя заменить контроль обработчика и частоты запросов. Послойный подход описан в рекомендациях OWASP по защите от автоматизированных злоупотреблений.

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

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

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

3. Проверьте серверный обработчик и все экземпляры формы

Виджет в браузере — только часть решения. У стандартной CAPTCHA Битрикса введённый код проверяется на сервере; соответствующий механизм описан в документации Bitrix Framework. Для сторонней капчи нужно выполнить серверную проверку по правилам её поставщика. Наличие заполненного поля с токеном не равно успешной проверке.

Разработчику стоит проследить весь путь запроса:

1. Получение данных. Обработчик принимает только ожидаемые поля и проверяет обязательные значения, длину текста и формат контактов.
2. Защитные проверки. Ограничение частоты, ловушка и капча выполняются до создания рабочего обращения и отправки уведомлений. Конкретный порядок выбирают с учётом стоимости проверок и поведения формы.
3. Решение. Ошибка пользователя, отказ антиспама и недоступность внешней проверки различаются в журнале.
4. Сохранение и передача. Принятая заявка сохраняется в предусмотренном месте, после чего отслеживается результат уведомления или передачи в CRM.
5. Ответ посетителю. Форма сообщает реальный результат и позволяет исправить ошибку без потери введённого текста.

Проверку сессии и защиту от CSRF сохраняют, но они не устанавливают, что запрос отправил человек. Назначение CSRF-защиты — предотвращать подделку запросов от имени пользователя; подробнее — в рекомендациях OWASP.

Капча прошла, но повторная отправка не работает

Рассмотрим условный сценарий: клиент прошёл капчу, ошибся в телефоне, исправил поле и снова нажал кнопку. Если первая попытка уже использовала одноразовый токен, повторная проверка того же токена не пройдёт. Например, у Yandex SmartCaptcha токен действует пять минут и может быть проверен только один раз — это указано в документации валидации. Для других сервисов условия могут отличаться.

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

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

4. Примите антиспам по контрольным сценариям

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

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

5. Оцените результат по принятым заявкам и причинам отказа

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

Для технической проверки полезно различать принятую заявку, отказ конкретного правила, ошибку заполнения и сбой проверочного сервиса. К событию добавляют время, идентификатор запроса, форму, результат и короткую причину. Идентификатор помогает связать проверку с сохранённой заявкой и уведомлением. Принципы такого журналирования описаны в руководстве OWASP по логам.

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

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

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

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

Капча уже стоит. Почему спам продолжает приходить?

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

Можно ли обойтись без видимой капчи?

Для части форм подходит сочетание ловушки, ограничения частоты и контроля повторов; иногда используется невидимая или дополнительная проверка для подозрительных отправок. Выбор зависит от фактического потока спама и результатов проверки обычных клиентов.

Нужно ли блокировать IP после первого подозрительного сообщения?

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

Означает ли спам через форму, что сайт взломан?

Сам по себе поток нежелательных отправок не подтверждает взлом. Если появились посторонние администраторы, изменённые файлы или неожиданные перенаправления, проверьте признаки компрометации сайта отдельно.

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