Спам через форму сайта перегружает почту и отвлекает сотрудников от полезных обращений. Защиту стоит собирать из нескольких проверок: каждая закрывает свой способ злоупотребления, а вместе они уменьшают поток мусора. При этом форма должна оставаться доступной человеку, который быстро заполнил поля, пользуется клавиатурой или отправляет заявку из общей офисной сети.
Начните с серверных правил и наблюдения за отправками. Затем настройте ограничения частоты и признаки автоматического заполнения. CAPTCHA добавляйте, когда понятно, какую оставшуюся проблему она должна решить. Ни один из этих способов не гарантирует полного устранения спама.
Сначала выясните, откуда приходят сообщения
Письмо с темой «Заявка с сайта» ещё не доказывает, что оно прошло через форму. Попросите разработчика сопоставить подозрительное обращение с записью о приёме запроса на сервере. Если такой записи нет, нужно проверить путь доставки и сам почтовый ящик: изменение формы может не затронуть источник мусора.
Разделите наблюдаемые ситуации:
- Массовые отправки. За короткий промежуток приходит серия обращений; важно ограничить нагрузку до отправки уведомлений и передачи данных в CRM.
- Редкий, но правдоподобный спам. Контакт заполнен корректно, сообщение похоже на обычный вопрос. Одного ограничения частоты недостаточно.
- Повтор полезной заявки. Человек нажал кнопку ещё раз после задержки. Нужно проверить подтверждение отправки и обработку дублей, прежде чем считать его ботом.
Перед изменениями зафиксируйте, какие формы затронуты, какие проверки уже работают и как часто сотрудник видит явно нежелательные обращения. Удалите личные данные из примеров, которые передаёте для первичного обсуждения. Если появились ещё и неизвестные изменения страниц или учётных записей, действуйте по отдельному порядку при подозрении на взлом сайта: спам сам по себе не подтверждает взлом.
Серверная проверка — обязательная основа
Проверки в браузере помогают человеку исправить ошибку до отправки. Но автоматическая программа может обратиться прямо к обработчику формы, минуя страницу и её JavaScript. Поэтому сервер должен сам решить, допустим ли запрос, прежде чем использовать его данные.
Для каждой формы согласуйте правила: какие поля обязательны, какой контакт нужен, какие значения можно выбрать, какова допустимая длина сообщения и размер запроса. Не превращайте свободный текст в поле, где разрешены только русские буквы: клиенту может понадобиться написать артикул, имя латиницей или адрес страницы, о которой он спрашивает.
Корректный формат контакта не подтверждает намерения отправителя. Бот тоже способен заполнить все обязательные поля. Валидация отсеивает некорректные данные и ограничивает их объём; оценка спама решает другую задачу. При выводе обращения в служебном интерфейсе данные также нужно безопасно обрабатывать: успешная проверка формы не делает произвольный текст безопасным для любого использования.
CSRF защищает от другой угрозы
CSRF — подделка запроса, который браузер посетителя отправляет на сайт по команде сторонней страницы. Особенно существенен этот риск для действий с авторизацией, когда браузер автоматически передаёт данные сессии. Защиту от него следует настраивать средствами используемой платформы и проверять на сервере.
CSRF-токен — служебное значение для проверки запроса. Он не является свидетельством того, что перед экраном человек: бот может открыть общедоступную форму, получить нужный токен и отправить его вместе со спамом. Поэтому работающая CSRF-защита и продолжающийся спам не противоречат друг другу.
Не отключайте эту проверку, чтобы устранить ошибку отправки. Разработчику нужно разобраться с сессией, передачей токена и устаревшей страницей. Пользователю следует дать понятный способ повторить попытку с сохранением введённого текста, насколько это возможно, без ложного сообщения об успехе.
Ограничьте частоту отправки, сохранив нормальные сценарии
Ограничение частоты, или rate limiting, задаёт допустимое число попыток за определённое время. Применяйте его к приёму формы до дорогих действий: почтовых уведомлений, задач очереди и запросов в CRM. Отключённая на странице кнопка этому не равнозначна.
Порог выбирают по обычным сценариям конкретного сайта. Универсальное число «заявок в минуту» здесь бесполезно: нужно учесть несколько форм, повтор после ошибки и посетителей из общей сети. IP-адрес не равен человеку — за одним адресом могут находиться разные пользователи. В то же время отправитель спама способен менять адреса, а ограничение только по сессии обходится созданием новой сессии.
Попросите разработчика объяснить, какие признаки учитываются независимо, какие попытки попадают в счётчик и как правило работает при одновременных запросах. Если приложение работает на нескольких серверах, ограничение должно сохранять согласованность между ними. Когда перед сайтом есть прокси, адрес клиента нужно определять только через доверенную конфигурацию, а не принимать произвольное значение из заголовка запроса.
При временном ограничении человек должен понимать, что отправка не состоялась и что можно сделать дальше. Не показывайте ему внутренние пороги и подробности фильтра. Сохраните ввод и возможность повторить действие; постоянная блокировка всей сети из-за короткой серии попыток требует отдельного обоснования.
Honeypot и другие признаки робота
Honeypot — дополнительное поле-ловушка, которое обычный пользователь не должен заполнять. Простая программа, заполняющая все найденные поля, может оставить в нём значение. Проверку выполняют на сервере; более сложный бот способен распознать ловушку и пропустить её.
Недостаточно просто убрать поле за край экрана. Оно не должно попадать в порядок перехода клавишей Tab или предлагаться экранным диктором как обязательный вопрос. Проверяйте также автозаполнение браузера: защитный механизм не должен наказывать человека за автоматически подставленный контакт. Атрибут запрета автозаполнения сам по себе не заменяет эту проверку.
Другие признаки — необычная скорость заполнения, повторяющийся текст, серия одинаковых действий — помогают оценить риск. Но быстрый ввод возможен и у человека с автозаполнением, а похожие вопросы могут задавать разные покупатели. Отсутствие движений мыши тоже не доказывает автоматическую отправку: пользователь может работать клавиатурой.
Мягкие признаки разумнее использовать вместе и сначала наблюдать их срабатывания. Если учитывается время заполнения, исходную отметку должен контролировать сервер: цифра, которую произвольно прислал браузер, не является надёжным основанием.
Когда нужна CAPTCHA
CAPTCHA и внешняя антибот-проверка могут стать дополнительным барьером, если базовые меры не справляются с наблюдаемым потоком. Но интерактивное задание добавляет шаг к отправке и может оказаться недоступным для части посетителей. Решение стоит оценивать по реальным отказам и полезным обращениям, а не только по количеству заблокированных запросов.
Установка виджета на страницу не завершает интеграцию. Для решения, которое выдаёт проверочный токен, сервер должен проверить его по правилам поставщика до принятия заявки. При подключении Turnstile такая серверная проверка обязательна; срок действия и повторное использование токена также учитываются. Успешная проверка не отменяет валидацию полей и ограничения частоты.
Согласуйте поведение при недоступности проверки. Пользователь должен увидеть, что заявка не принята, сохранить введённый текст и получить доступный способ связи. Если бизнесу нужен резервный приём обращений, его проектируют и ограничивают отдельно; ошибка внешнего сервиса не должна автоматически отключать всю защиту формы.
Для интерактивной CAPTCHA проверьте управление клавиатурой и доступные альтернативы для разных возможностей восприятия. Надпись «проверка пройдена» без возможности самостоятельно пройти её проблему доступности не решает.
Как не потерять полезные обращения
Ложное срабатывание — ситуация, когда защита мешает реальному клиенту. Побочный эффект может выглядеть как успешное сокращение спама, если следить только за входящей почтой.
| Что заметили | Что проверить | Как скорректировать защиту |
|---|---|---|
| Жалобы от посетителей одной организации | Общий IP и причину ограничения | Уточнить условия счётчика, сохранив защиту от массовых отправок |
| Отказ сразу после автозаполнения | Поле-ловушку и проверку скорости | Исправить попадание нормального ввода под правило |
| Отказы после долгого заполнения | Сессию и срок действия служебных токенов | Дать способ обновить проверку без потери сообщения |
| Мусора меньше, полезных заявок тоже | Приём на сервере, отказы и доставку обращений сотруднику | Найти этап потери, прежде чем ужесточать фильтр |
Учебный пример. В форме заказа услуги ввели жёсткий лимит по IP. После этого сотрудник перестал получать часть обращений из офисной сети заказчика. Увеличивать все пороги вслепую или отключать защиту не нужно: сначала воспроизводят отправки разных пользователей из общей сети, сопоставляют их с причиной отказа и меняют конкретное правило. Это пример для объяснения, а не история клиентского проекта.
Для диагностики полезны время, идентификатор попытки, форма, версия правила, причина решения и итог приёма. Тексты сообщений, контакты и служебные токены не нужно без необходимости копировать в технический журнал. Ограничьте доступ к нему и срок хранения. Сотрудник, проверяющий нежелательные обращения, должен иметь возможность сообщить об ошибочной классификации.
Сомнительные обращения при необходимости можно направлять в отдельную очередь проверки. Она должна иметь ответственного, ограниченный объём и срок хранения: иначе спам просто переносится из почты в другой бесконтрольный архив. Этот вариант подходит только там, где бизнес способен регулярно разбирать очередь.
Что включить в задачу разработчику и приёмку
Опишите наблюдаемую проблему, формы и путь заявки до сотрудника. Попросите зафиксировать правила, причины отказа, возможность их настройки и порядок возврата прежних параметров при ошибке. Проверки сначала выполняют в тестовой среде с явно учебными данными; нагрузочные попытки на рабочем сайте отдельно согласуют.
При приёмке проверьте следующие сценарии:
- Обычная заявка с телефона и компьютера принята и дошла по согласованному маршруту.
- Клавиатура, экранный диктор и автозаполнение не заставляют пользователя взаимодействовать с ловушкой.
- Прямой запрос к обработчику без страницы проходит все необходимые серверные проверки; некорректные данные отклоняются до уведомлений.
- Серия запросов, в том числе одновременных, вызывает согласованное ограничение. Поведение нескольких посетителей из общей сети проверено отдельно.
- Устаревший токен, временный отказ внешней проверки и повтор после сетевой ошибки дают понятный результат; форма не сообщает об отправке непринятого обращения.
- По журналу можно объяснить решение фильтра, а сотрудник способен передать разработчику пример ложного срабатывания без раскрытия лишних данных.
После включения сравнивайте нежелательные сообщения, отказы и подтверждённо доставленные полезные обращения за сопоставимые периоды. Отсутствие жалоб не доказывает, что потерь нет: часть посетителей просто уйдёт. Новые правила вводите так, чтобы было понятно, какое изменение повлияло на результат.
Обследование обработчиков и защитных настроек можно обсудить в рамках безопасности сайта. Изменение конкретной формы, обработки ошибок и маршрута заявки — как доработку сайта. По условиям Студии Вебирус чужие проекты принимаются после диагностики; подходящий состав и объём работ согласуют по состоянию сайта. Результатом задачи должны стать проверяемые правила и доступная форма, а не обещание навсегда убрать весь спам.
