Precursor は、訪問者の行動を時間をかけて継続的に評価する、クライアントサイドのセッションベース検証システムです。1 回の Challenge に頼るのではなく、ブラウザ内で検証を続け、個別リクエストでは正当に見えてもセッション全体では人間らしくないパターンを示す自動化を検出します。
Precursor は、クライアントサイドの継続的な検証ループとして動作します。
- ページにクライアントサイドスクリプトが注入されます
- スクリプトはシグナルを集め続け、検証を行います
- 各実行で得られたシグナルを Cloudflare が評価します
- 結果は
cf_clearanceCookie に保存されたセッション状態の更新に使われます - この処理がセッション中ずっと繰り返されます
これにより、Cloudflare はセッションの行動を時間をかけて継続的に評価できます。
ゾーンで Precursor を有効にします。
-
Cloudflare ダッシュボードでゾーンを選びます。
-
Security > Settings を開きます。
-
Precursor を探します。
-
Precursor をオンにします。
-
モードを選びます: ユーザーセッションを十分に検証するには、有効なセッションを確立するために、訪問者が軽量な Challenge を完了する必要がある場合があります。Precursor には、ユーザー体験を優先するか、厳密な検証を優先するかに応じた 2 つのモードがあります。
-
Minimize Friction(デフォルト) 訪問者にインタースティシャルの Challenge を表示しません。代わりに、Precursor はバックグラウンドでセッション状態の確立を試みます。 ユーザー体験は滑らかになりますが、すべてのセッションが十分に検証されることは保証できません。
-
Maximize Security(推奨) 有効なセッションがまだない場合、軽量なインタースティシャル Challenge を表示してセッションを確立します。 ユーザーが進む前にすべてのセッションが検証されますが、摩擦が増えることがあります。
-
ほとんどの顧客では、モードの選択だけが必要な設定です。
Precursor はデフォルトでゾーン全体で動作します。Precursor Rules は Precursor の有効 / 無効を切り替えるものではなく、各リクエストにどのモードを適用するかを決めます。
例:
- サイト全体では Minimize Friction を使い、
/checkoutでは有効なセッションを強制するために Maximize Security を使います。 - すべてのページで Maximize Security を使い、ホームページだけ例外にします。
ゾーンがブラウザ向けページと API エンドポイントの両方を提供している場合は、Precursor Rules で厳密な適用範囲を絞ります。
Precursor が Maximize Security のとき、リクエストは有効な cf_clearance Cookie を提示する必要があります。影響を受ける可能性があるのは次のとおりです。
- ブラウザ以外のクライアントが呼ぶ API エンドポイント(例:
curl、モバイルバックエンド、サーバー間ジョブ) - Cookie を送らないブラウザからの API 呼び出し
HTML と API が混在するトラフィックでは、次のいずれかのパターンを使います。
- グローバルでは Minimize Friction から始め、機密ページやパスだけ Precursor Rules で Maximize Security を適用します。
- グローバルでは Maximize Security から始め、API ホスト名または API パスに Minimize Friction の Precursor Rules を追加します。
Maximize Security 配下のエンドポイントへアクセスするブラウザの XHR / fetch では、Cookie を含めてください。
fetch("/api/search", {
credentials: "include",
});axios.get("/api/search", {
withCredentials: true,
});Challenge 形式のセッション強制が不要なエンドポイントでは Minimize Friction を使います。Precursor はセッション行動の評価を続け、検出シグナルとボットスコアの文脈にも寄与できます。
Precursor は JavaScript Detections(JSD)の後継です。JSD も Precursor もクライアントサイドのシグナルを集めますが、Precursor は 1 回のチェックではなく、セッション全体で継続的に評価します。
- Precursor は 1 回の実行から継続検証へ移ります
- Precursor はセッションベースの状態を導入します
- Precursor は動的なランタイム制御を可能にします
JSD または Precursor がボットスコアに寄与する場合、Cloudflare はそのソースを JavaScript Fingerprinting として公開します。
Precursor を有効にすると、同じトラフィックで両方を動かさないよう、Cloudflare は JSD を無効にします。Precursor には、以前 JSD がカバーしていた検出がすべて含まれます。JSD 駆動の Security Rules は引き続き適用されます。
以前 JSD を使わずに Precursor を有効にすると、ボットスコアが 30 未満のトラフィックが増えることがあります。
Precursor と Challenge の役割は異なります。
- Challenge は時点の検証を提供します
- Precursor は継続的なセッション単位の検証を提供します
Precursor は Challenge を置き換えるものではありません。次の点で Challenge を強化します。
- 追加の Challenge が必要なタイミングを判断します
- Challenge を通過したあとも訪問者を再評価します
- 時間とともに現れる自動化を特定します
Precursor は cf_clearance と密に連携します。Precursor の実行中は次のことが起きることがあります。
- 実効的な clearance が低下または無効化される
- 追加の Challenge がトリガーされる
- 同じセッション中に訪問者が再検証される
ゾーンで Precursor が動作すると、検出結果はそのゾーンの Analytics ビューに表示されます。開くには、Cloudflare ダッシュボードでゾーンを選び、Security > Analytics > Traffic > Bot analysis を開きます。ボットスコア分布と WAF ルール一致数に、Precursor の検出が含まれます。
詳細は Security Analytics を参照してください。