第06章：Turnstileはフォームの入口を守る仕組み 🧩🛡️

Turnstileは、フォーム送信やログイン画面をbotや自動送信から守るための仕組みです。
ユーザー体験を重くしすぎずに、怪しいアクセスを減らすために使えます。
この章では、Turnstileの全体像をつかみます 😊

Turnstile Concept

1. Turnstileで守りたいもの 🚪

Turnstileは、次のような入口に向いています。

こうした場所は、botに連打されたり、スパムを送られたりしやすいです。

Turnstileは、フォーム送信前に検証用トークンを発行し、それをサーバー側で確認する流れです。

Turnstileには、site keyとsecret keyがあります。

site key
ブラウザ側に置くキーです。ウィジェット表示に使います。

secret key
サーバー側、つまりWorker側でSiteverify APIを呼ぶために使います。

secret keyをReact側に置いてはいけません。
secret keyが漏れると、Turnstileの検証を突破される危険があります。

Site Key vs Secret Key

Cloudflare公式は、Turnstileのサーバー側検証が必須だと案内しています。
なぜなら、攻撃者はブラウザ画面を通らずに、直接フォームAPIへリクエストできるからです。

つまり、画面にウィジェットがあるだけでは不十分です。

必要な流れはこうです。

React画面でTurnstile tokenを受け取る
  ↓
tokenをWorkers APIへ送る
  ↓
WorkerがSiteverify APIで検証する
  ↓
成功したらフォーム処理

Turnstile Validation Flow

Turnstileのtokenには特徴があります。

古いtokenや再利用tokenは、timeout-or-duplicate のようなエラーになることがあります。

フォームを長時間開いたままにした場合は、tokenを更新する必要があります。

Token Properties

最初の学習では、問い合わせフォームに入れるのが分かりやすいです。

/contact
  ↓
POST /api/contact

React側でTurnstile tokenを受け取り、/api/contact へフォーム内容と一緒に送ります。
Worker側で検証してから、メール送信や保存処理へ進みます。

Contact Form Example

この章で覚える一言はこれです。
Turnstileは画面に置くだけでは未完成。Worker側で検証して初めて守りになります 🧩🔐