Защита веб-форм от ботов: сравниваем методы и выбираем

Если форму регистрации или обратной связи атакуют боты, одна капча редко решает проблему: её могут обходить, а пользователи — не пройти. Надёжнее сочетать несколько мер: ограничивать частоту отправок, проверять поведение формы и добавлять испытание только при подозрении на автоматизацию. Ниже сравниваем подходы без привязки к фреймворку; для ответа сервера при ограничении скорости ориентируемся на HTTP 429 из RFC 6585.

Сначала определите, что именно атакуют

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

До выбора механизма выясните, где запрос становится дорогим. Это может быть создание записи, отправка письма, обращение к платёжной системе или проверка пароля. Ограничение стоит применять до дорогой операции, а проверки на сервере — выполнять независимо от того, какие поля и сценарии показывает браузер.

Термин: ложное срабатывание — ситуация, когда защитная проверка принимает обычного посетителя за бота и мешает ему отправить форму.

Четыре подхода и цена каждого

1. Ограничение частоты запросов

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

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

2. Скрытое поле и проверка времени

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

Не используйте эти сигналы как единственное основание для жёсткой блокировки. Автозаполнение, менеджер паролей, медленная сеть или особенности доступности могут выглядеть необычно для простого правила. Безопаснее отправить подозрительную заявку на дополнительную проверку или ограничить её частоту.

3. CAPTCHA или другая проверка на стороне клиента

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

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

4. Очередь, задержка и ручная модерация

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

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

Как выбрать комбинацию

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

1. Установите базовый лимит. Считайте запросы до дорогой обработки и не опирайтесь только на IP. Проверьте, что при нескольких экземплярах приложения лимит общий, иначе каждый сервер будет считать попытки отдельно.
2. Добавьте малозатратные сигналы. Проверьте honeypot и время заполнения, но не блокируйте посетителя автоматически по одному признаку. Убедитесь, что скрытое поле не мешает экранным дикторам и автозаполнению.
3. Включайте CAPTCHA по риску. Проверяйте результат на сервере и предусмотрите путь для тех, кто не может пройти задание. Сравните число остановленных автоматических заявок с долей незавершённых обычными пользователями.
4. Защитите дорогие побочные действия. Не отправляйте письмо и не запускайте внешнюю операцию до прохождения серверных проверок и ограничения частоты. Для всплесков используйте очередь, если задержка допустима.
5. Настройте ответ и наблюдение. При временном ограничении запросов сервер может вернуть HTTP 429; при необходимости клиенту сообщают, когда повторить попытку, через Retry-After. Сверяйте метрики отправок, отказов и обращений в поддержку, чтобы заметить как атаку, так и слишком строгие правила.

Что ломается в проде

Общий IP получает блокировку. Так бывает в офисе, учебном заведении или мобильной сети. Ослабьте правило, добавьте другие сигналы и проверьте, что лимит не блокирует весь адрес из-за действий одного пользователя.

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

Заголовок с IP подделывают. Не считайте произвольный X-Forwarded-For достоверным. Настройте список доверенных прокси и определите, откуда приложение получает адрес клиента.

Защита пропускает запрос до проверки. Проверка в браузере полезна для интерфейса, но её можно обойти прямым запросом. Сервер должен сам проверять поля, лимиты и токены сторонней проверки.

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

Что проверить дальше

Начните с одной формы и измерьте базовый уровень: число отправок, долю отклонённых запросов, задержку до ответа и нагрузку от обработки заявок. Затем включайте ограничения постепенно и проверьте сценарии с общим IP, отключённым JavaScript и повторной отправкой. Если используете стороннюю CAPTCHA, отдельно проверьте серверную валидацию и условия обработки данных. Инвалидация уже созданных спам-записей — отдельная задача; здесь речь только о предотвращении автоматических отправок.