Cloudflare Turnstile для WordPress: защита форм от спама без reCAPTCHA

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

Cloudflare Turnstile можно использовать на сайтах, которые не проксируются через Cloudflare. Ниже разберём, как встроить Turnstile в WordPress правильно: показать виджет, получить токен, проверить его через Siteverify и только после этого выполнять полезное действие — отправлять письмо, создавать лид или записывать заявку.

Чем Turnstile отличается от обычной капчи

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

Cloudflare отдельно указывает, что Turnstile работает как самостоятельный сервис и может использоваться на любом сайте, даже если сам домен не использует Cloudflare CDN или proxy.

Sitekey и secret key: что где хранить

После создания виджета используются два разных значения:

• sitekey — публичный идентификатор, его нормально видеть в HTML страницы;
• secret key — секрет для серверной проверки, он не должен попадать в браузер, JavaScript, публичный репозиторий или HTML.

В WordPress секрет можно хранить в серверной конфигурации, переменной окружения или настройке, недоступной фронтенду. Конкретный вариант зависит от инфраструктуры сайта.

Куда добавлять виджет в WordPress

Turnstile можно встроить в собственную форму, кастомный AJAX endpoint или адаптер существующего плагина форм. Важнее не место визуального блока, а то, чтобы обработчик формы получил токен и проверил его до выполнения действия.

Для кастомной разработки обычно удобно разделить интеграцию на два слоя:

1. frontend выводит контейнер Turnstile и передаёт полученный токен вместе с формой;
2. backend валидирует nonce/права WordPress там, где это применимо, санитизирует поля и отдельно проверяет Turnstile через Siteverify.

Почему одной клиентской проверки недостаточно

Если сервер доверяет скрытому полю вроде turnstile_ok=1 или только факту выполнения JavaScript, злоумышленник может отправить POST напрямую. Такой запрос минует визуальный интерфейс полностью.

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

Срок жизни и повторное использование токена

Это особенно важно для AJAX-форм и длинных форм. Cloudflare указывает, что токены Turnstile действуют 300 секунд и являются одноразовыми. Повторная проверка уже использованного токена завершится неуспешно.

Практические последствия:

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

Пример серверной проверки в WordPress

Ниже упрощённый пример. Он показывает порядок действий, а не готовый плагин. Реальный секрет в код вставлять не нужно.

<?php
function asg_verify_turnstile( $token, $remote_ip = '' ) {
    $secret = getenv( 'TURNSTILE_SECRET_KEY' );
    if ( ! $secret || ! $token ) { return false; }
    $body = array( 'secret' => $secret, 'response' => $token );
    if ( $remote_ip ) { $body['remoteip'] = $remote_ip; }
    $response = wp_remote_post( 'https://challenges.cloudflare.com/turnstile/v0/siteverify', array( 'timeout' => 10, 'body' => $body ) );
    if ( is_wp_error( $response ) ) { return false; }
    $data = json_decode( wp_remote_retrieve_body( $response ), true );
    return ! empty( $data['success'] );
}

После этой функции обработчик должен остановиться при false. Только успешная проверка открывает путь к дальнейшей логике.

Turnstile и WordPress nonce решают разные задачи

Nonce WordPress помогает защитить действие в контексте WordPress от определённых видов подделки запросов, но не является антибот-системой. Turnstile, наоборот, не заменяет проверку прав пользователя, nonce, валидацию полей или контроль доступа.

Для формы в личном кабинете может понадобиться одновременно:

• проверка авторизации и capability;
• WordPress nonce;
• валидация и sanitization входных данных;
• Turnstile для антибот-проверки;
• rate limiting для чувствительного endpoint.

Что делать с AJAX-формой

С AJAX принцип тот же. JavaScript получает токен Turnstile и добавляет его в запрос. PHP-обработчик не доверяет браузеру и выполняет Siteverify самостоятельно.

Если форма после ошибки остаётся открытой, важно понимать, был ли токен уже проверен. Из-за одноразовости безопаснее инициировать получение нового токена перед повторной отправкой.

Защита нескольких форм на одной странице

Если на странице есть форма обратной связи, заказ звонка и подписка, нужно заранее решить, будет ли у каждой формы свой экземпляр виджета и собственный токен. Не стоит передавать один токен между несколькими endpoint.

Для динамических popup и SPA-подобных интерфейсов удобнее явный рендеринг виджета в момент открытия формы и корректный reset после завершения попытки.

Hostname и окружения

Для рабочего сайта и staging лучше заранее продумать отдельные настройки и разрешённые hostname. Это уменьшает риск случайно использовать production-секрет в тестовом окружении.

Cloudflare предоставляет тестовые sitekey/secret для разработки. Для автоматизированных тестов лучше использовать предусмотренные тестовые значения, а не отключать проверку условием «если staging — пропустить».

CSP и загрузка скрипта

Если на сайте настроена строгая Content Security Policy, интеграция Turnstile должна учитывать домен challenges.cloudflare.com в соответствующих директивах. Не стоит копировать и самостоятельно кешировать Turnstile API-скрипт — подключение должно соответствовать актуальной документации Cloudflare.

Типовые ошибки интеграции

Turnstile не заменяет антиспам-архитектуру целиком

Даже корректная Turnstile-проверка не означает, что endpoint можно оставить без других ограничений. Для форм с высокой ценностью атаки полезны rate limiting, серверная валидация, ограничения по частоте и мониторинг аномалий.

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

Когда достаточно готового плагина

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

Когда лучше сделать свою интеграцию

Кастомная реализация полезна для собственных AJAX-форм, нестандартного checkout, личного кабинета, интеграции с CRM или когда один и тот же endpoint выполняет несколько чувствительных действий. В таких проектах Turnstile становится частью общей серверной цепочки.

Для нестандартной формы можно заказать доработку WordPress или полноценную WordPress-разработку.

Вывод

Правильная интеграция Turnstile с WordPress состоит из двух половин: удобной проверки в браузере и обязательной проверки токена на сервере. Если второй половины нет, визуальный виджет создаёт ощущение защиты, но endpoint остаётся доступным для прямых автоматизированных запросов.

Если нужно защитить нестандартные формы, checkout или собственный API endpoint, можно описать задачу A.S Groups и встроить Turnstile в существующую серверную логику без ломки формы.

Официальные источники

• Cloudflare Turnstile — Get started
• Cloudflare Turnstile — Validate the token
• Cloudflare Turnstile — Client-side rendering
• WordPress Developer Resources — wp_remote_post()