Формы в 1С-Битрикс: валидация, капча и защита от спама

Формы на 1С-Битрикс часто живут долго: сначала это простая форма обратной связи, потом к ней добавляют маску телефона, согласие, AJAX, капчу, цели аналитики, отправку письма и запись в CRM. Через несколько лет становится сложно понять, почему заявки не приходят или почему приходит много спама.

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

Проверить обязательные поля

Клиентская проверка в браузере удобна, но недостаточна. Любую форму можно отправить напрямую, минуя JavaScript. Поэтому обязательные поля должны проверяться на сервере.

if (trim($name) === '' || trim($phone) === '') {
    $errors[] = 'Заполните имя и телефон';
}

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

Маска телефона

Маска телефона часто создаёт ложное ощущение защиты. Бот может отправить любое значение напрямую. На сервере лучше нормализовать телефон и проверить минимальную длину.

$phoneDigits = preg_replace('/\D+/', '', $phone);

if (strlen($phoneDigits) < 10) {
    $errors[] = 'Некорректный телефон';
}

При этом не стоит делать слишком жёсткую проверку, если форма может принимать разные форматы номеров.

Капча

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

Если капча уже подключена, нужно проверить два сценария: неправильная капча должна отклоняться, правильная — пропускать форму. Иногда после AJAX-перерисовки токен капчи устаревает.

Honeypot

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

<input type="text" name="company_site" value="" style="display:none" tabindex="-1" autocomplete="off">

if (!empty($_POST['company_site'])) {
    return;
}

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

Ограничение частоты

Если с одного IP за минуту приходит много заявок, стоит ограничить частоту. Делать это можно через кэш или собственную таблицу.

$ip = $_SERVER['REMOTE_ADDR'];
$cache = \Bitrix\Main\Data\Cache::createInstance();
$cacheId = 'form_rate_' . md5($ip);

if ($cache->initCache(60, $cacheId, '/form_rate/')) {
    return;
}

if ($cache->startDataCache()) {
    $cache->endDataCache(['sent' => true]);
}

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

Почтовое событие

Если форма прошла валидацию, но письмо не пришло, нужно проверить CEvent::Send, EVENT_NAME и шаблон письма.

CEvent::Send(
    'FORM_FEEDBACK',
    SITE_ID,
    [
        'NAME' => $name,
        'PHONE' => $phone,
        'EMAIL' => $email,
    ]
);

Макросы в шаблоне должны совпадать с переданными ключами. Если шаблон ждёт #PHONE#, а код передаёт USER_PHONE, письмо будет неполным.

Логирование

На время диагностики полезно писать результат обработки формы в лог. Не нужно хранить лишние персональные данные постоянно, но ID заявки, IP, статус и ошибку можно фиксировать.

\Bitrix\Main\Diag\Debug::writeToFile(
    [
        'status' => 'validation_failed',
        'errors' => $errors,
    ],
    'feedback',
    '/local/logs/forms.log'
);

Чек-лист

1. Проверить HTML-поля и их name.
2. Проверить серверную обязательность полей.
3. Нормализовать телефон на сервере.
4. Проверить капчу на успешный и ошибочный сценарий.
5. Добавить honeypot, если много простого спама.
6. Настроить ограничение частоты отправки.
7. Проверить почтовое событие и шаблон.
8. Добавить аккуратное логирование ошибок формы.

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