Turnstile Spin инсталира защитата, но сървърната проверка остава решаваща

В публикацията си от 25 септември 2026 г. Cloudflare представи Turnstile Spin като начин AI агент да добави Turnstile уиджет и сървърно извикване към Siteverify; според компанията от пускането през юли чрез Spin са създадени над 65 000 уиджета, а генерираната инструкция е копирана над 30 000 пъти. Работният процес обхваща нова инсталация, поправка на вече поставен уиджет без сървърна проверка и миграция от друга CAPTCHA система.

Публикуваният същия ден анализ на Fervor AI посочва оставащия риск: видимият уиджет и промените в кода не доказват, че защитеният адрес отхвърля невалидна заявка. За собственика на сайта решаващото е дали бекендът изчаква отговора от Siteverify и спира заявката, когато проверката е неуспешна. Най-прекият тест е заявка към самия обработчик.

Какво поема агентът при инсталацията

При работа с AI агент Spin го насочва да намери подходящите места в кода, да постави Turnstile уиджет във формуляра и да добави извикването към Siteverify в съществуващия сървърен обработчик. Агентът предлага план и изчаква одобрение, преди да редактира проекта. Кодът остава в приложението на потребителя, а решението дали защитеното действие да продължи се взема в неговия бекенд.

Началното състояние определя какво ще се промени. При нова инсталация са нужни клиентски уиджет и сървърна проверка. Когато уиджет вече обслужва заявки, но няма съответстващи извиквания към Siteverify, в таблото се появява „Fix with Spin“ и агентът насочва промяната към липсващата сървърна част. При миграция той открива маркери на използваната CAPTCHA система и предлага замяната ѝ за одобрение.

Spin може да се стартира през таблото на Cloudflare, през Wrangler или чрез инструкция към съвместим AI агент, но тези входни точки не вършат една и съща работа: Wrangler може да създаде уиджета, докато вграждането му и сървърната логика се довършват в проекта. Автоматизацията спестява ръчното търсене на места за промяна, но успешното създаване на уиджет не е резултат от тест на защитения адрес. Именно там се различават завършена редакция на кода и работещо ограничение за заявките.

Къде токенът става защита

Клиентският уиджет издава токен, който формулярът изпраща със заявката. Според документацията на Cloudflare за Siteverify токенът е валиден 300 секунди и може да бъде проверен само веднъж; повторна проверка връща грешка „timeout-or-duplicate“. Бекендът изпраща токена и тайния ключ чрез POST заявка към Siteverify и получава отговор дали проверката е успешна.

Успешният отговор трябва да е условие за изпълнение на защитеното действие, а не информация, записана след него. Ако обработчикът приема заявката при липсващ токен, неуспешен отговор или недостъпен Siteverify, уиджетът може да изглежда изправен, докато самият адрес остава достъпен без проверка. Затова решението за отказ трябва да предхожда създаването на профил, изпращането на съобщение или друга операция, която формулярът задейства.

Тайният ключ принадлежи в сървърна променлива на средата или хранилище за тайни, а не в код, който браузърът получава. Публичният sitekey има друга роля: той указва кой уиджет работи на страницата. При успешна проверка отговорът на Siteverify съдържа hostname на страницата, а при зададен action връща и него. Сравняването им с очакваните стойности в бекенда обвързва успешната проверка с конкретния сайт и действие; само поле „success“ не установява тази връзка.

Кратък одит след промяната на Spin

Прегледът на кода показва какво агентът е възнамерявал да добави; заявки към защитения адрес показват как приложението се държи. Одитът трябва да включва както нормална заявка, така и опити без валиден токен, защото браузърният уиджет не контролира директните извиквания на бекенда. Проверяват се следните отделни условия:

1. Тайният ключ е достъпен само за сървърния процес и отсъства от клиентските файлове, публичната конфигурация и отговора на страницата. Проверява се и дали същата тайна е настроена в средата, където действително работи защитеният адрес; правилният локален файл не доказва правилна продукционна настройка.
2. Директна заявка към защитения адрес без токен се отказва, както и заявка с произволна невалидна стойност. Важно е да не настъпи защитеното действие, а не само да се появи съобщение за грешка в интерфейса. Така се проверява сървърното условие независимо от видимото състояние на уиджета.
3. Пресен валиден токен позволява предвидената операция, а повторна заявка със същия токен не я изпълнява отново. Отделно изтекъл токен и временен отказ на Siteverify трябва да доведат до отказ на защитеното действие. Това проверява дали обработчикът използва резултата от проверката, вместо само да изпраща заявка към Cloudflare.
4. Hostname от отговора на Siteverify съвпада с очаквания за съответната среда, а action съвпада с формуляра, когато е настроен. Локален hostname не трябва да се приема за продукционния адрес. Така успешен токен от друга разрешена страница или за друга операция няма автоматично да получи същото право в приложението.

Работният процес на Spin предвижда проверка с реален токен и повторение на заявката, но при недостъпен за тест бекенд успешната редакция на кода не доказва успешно блокиране. Дори когато в таблото се виждат извиквания към Siteverify, това показва наличие на трафик към услугата, а не какво е направил обработчикът след нейния отговор. За сайта последствието е пряко: защитената операция трябва да остане неизпълнена при отказ от Siteverify, независимо дали формулярът изглежда напълно готов.