Turnstile Spin 補上網站漏掉的後端驗證步驟
Cloudflare Blog · 2026-09-25
很多網站導入 Turnstile 時只在前端貼上小工具，從未在後端呼叫驗證介面，機器人照樣暢通無阻，防護等於沒有作用。Cloudflare 推出的 Turnstile Spin 就是針對這個缺口，用 AI coding agent 直接把遺漏的後端驗證補進程式碼裡。修法涵蓋全新安裝、幫舊有 widget 補上驗證、以及把其他驗證碼服務換成 Turnstile 這三種情境。
只驗證前端，後端從來沒檢查過
Turnstile 的正常整合分成兩段：前端頁面嵌入 widget，使用者完成挑戰後瀏覽器會拿到一組驗證 token，也就是表單裡的 cf-turnstile-response 欄位。後端收到表單送出的請求後，還必須另外呼叫 Cloudflare 的 siteverify API，把這組 token 連同 secret key 一起送過去，才能確認使用者真的通過了驗證。多數團隊只做了第一步，把 widget 貼在頁面上、畫面出現驗證方塊就當作完工，沒有人檢查後端是否真的呼叫了 siteverify。這樣一來，cf-turnstile-response 只是表單裡一個普通的字串，任何人都能繞過瀏覽器直接送出偽造或空白的值，伺服器一樣照單全收。
這個缺口不容易在功能測試中被發現，因為前端的挑戰畫面一切正常，使用者體驗跟正確整合幾乎沒有差別。唯一會看到差異的是後端的請求記錄：沒有對外呼叫 siteverify，也沒有任何驗證失敗或成功的紀錄，等於整個防護只存在於瀏覽器那一端。對機器人與自動化腳本來說，只要跳過瀏覽器、直接打表單背後的 API，就完全不會碰到那個看似有效的挑戰畫面。
採用的方法：讓 AI agent 直接改程式碼
Turnstile Spin 可以透過 Cloudflare 控制台（dashboard）啟動，也可以用 Wrangler CLI 執行，或者直接把一段公開的 skill 網址貼進正在使用的 AI coding agent。文章特別說明，不論是 Claude Code、Cursor、Codex 或其他 agent，都是同一支 agent 在使用者自己的程式碼庫裡動手修改，Cloudflare 不會把應用程式碼上傳到自己的伺服器、也不會遠端幫忙改。agent 會先掃描現有程式碼，找出前端是否已經嵌入 widget、後端是否已經有驗證呼叫，再列出一份修改計畫。使用者確認計畫之後，agent 才會同時動手改前端與後端的程式碼，而不是只補其中一邊。
這套流程涵蓋三種情境：全新安裝時同時建立前端 widget 與後端 siteverify 呼叫、幫既有但只做了前端的 widget 補上遺漏的驗證呼叫、以及把其他驗證碼服務直接換成 Turnstile。第二種情境正是這篇文章要處理的核心問題，也就是本文一開始描述的只驗前端、沒驗後端的部署方式。
對誰有影響：自己接過 Turnstile 的人要回頭檢查什麼
受影響的是自己串接過 Turnstile 的網站管理者與開發者，尤其是當初只依照前端教學貼上 widget、後續沒有再回頭檢查後端程式碼的人。具體要檢查的地方很直接：後端程式裡有沒有對 https://challenges.cloudflare.com/turnstile/v0/siteverify 發出過請求、有沒有把送出的 cf-turnstile-response token 連同 secret key 一起送過去查驗，以及驗證失敗時後端是否真的擋下請求。如果這幾項都是空白，代表現有的 Turnstile 部署就是文章描述的那種只有畫面、沒有防護的狀態，可以用 Turnstile Spin 直接補上對應的後端呼叫，不必整段重寫。
只驗證前端 widget（無效防護）
瀏覽器 -> 顯示 Turnstile 挑戰 -> 使用者過關 -> 表單送出 cf-turnstile-response
後端 -> 直接寫入資料庫，從未檢查 cf-turnstile-response
含後端 siteverify 呼叫（Turnstile Spin 補上的部分）
瀏覽器 -> 顯示 Turnstile 挑戰 -> 使用者過關 -> 表單送出 cf-turnstile-response
後端 -> 帶著 cf-turnstile-response 與 secret key 呼叫 siteverify
siteverify 回傳 success -> 後端才寫入資料庫；回傳失敗 -> 後端擋下請求原始來源：Cloudflare Blog