Cloudflare Precursorは、訪問者を一度だけ判定するのではなく、session中の行動変化をclient-side JavaScriptで継続評価する。Challenge通過後でもclearanceを再評価し、bot scoreへsession contextを反映できる。防御力は上がる一方、API endpointやSPAのfetch設定を誤ると正規sessionが再challengeされる可能性がある。

何が変わったか

Precursorは全顧客へrolloutされ、行動signalの継続評価、challenge clearanceの再検証、session context付きbot score、client-side visibilityを提供する。既存のSecurity Rulesと統合し、dashboardでsecurityとfrictionのmodeを選択できる。

変更前後の差

JavaScript Detectionsは一回の実行結果を主に使っていた。Precursorはsession stateとdynamic runtime controlを持ち、時間経過後に現れるautomationも検出する。Cloudflare Docsは、Precursorを有効にする場合はJavaScript Detectionsを無効にするよう案内している。Challenge Pagesはpoint-in-time verification、Precursorはcontinuous verificationであり、置換関係ではない。

誰に影響するか

login、checkout、search、form、API callをbrowserから実行するWeb applicationが対象である。SPAやmobile webでXHR/fetchを多用する場合、credentials: includeやwithCredentialsがないrequestはMaximize Security下で期待どおりclearanceを送れない可能性がある。

期限

強制設定期限はない。rollout中のため、zone全体へ強いmodeを適用せず、観測期間を設ける。

必要な対応

最初はMinimize Frictionを全体へ適用し、account takeoverやpaymentなどsensitive pathだけruleでMaximize Securityへ上げる。API hostname、health check、machine-to-machine pathは適用対象を分ける。cf_clearance、challenge loop、bot score分布、conversionを同時に見る。

実装・移行手順

  1. 現在のJavaScript DetectionsとChallenge ruleをinventory化する
  2. stagingまたは低risk zoneでPrecursorを有効化する
  3. Minimize Frictionでbot analysisを観測する
  4. XHR/fetchがcookieを送ることを確認する
  5. sensitive pathへ限定ruleを追加する
  6. challenge率、false positive、conversion、latencyを比較する
  7. JavaScript Detectionsを無効化する
  8. incident時のmode切替手順を演習する

失敗しやすい点

PrecursorがChallengeを完全に置き換えると思う、JSDを同時運用する、全pathをMaximize Securityにする、API requestでcookieを送らない、bot scoreだけでblockする、といった問題が起きやすい。session判定はdevice共有やprivacy設定の影響も受ける。

リスク

正規利用者の再challenge、login loop、SPA API failure、conversion低下、monitoring botの遮断がある。強いmodeを広範囲に適用すると、security event増加が攻撃増加なのか設定変更なのか判別しにくくなる。

評価方法

  • challenge solve率と再challenge率
  • bot score分布の変化
  • false positive問い合わせ件数
  • login・checkout成功率
  • API 401・403率
  • conversion率
  • automation detectionの増分
  • page・API latency

ロールバック

問題が出たpathのruleをMinimize Frictionへ戻し、必要ならPrecursorを無効化する。JSDへ戻す場合は同時有効化を避け、切替順序を明示する。設定変更前後のSecurity Analyticsを保存し、rollback後にscoreとerror rateが戻ったか確認する。

編集部分析

session-based detectionは、攻撃者が最初だけ人間らしく振る舞う回避策へ対応する。運用の焦点はblock率ではなく、継続判定によって正規sessionの体験を壊していないかにある。securityとUXを同じdashboardで評価する体制が必要である。

実務チェックリスト

  • [ ] JSDとPrecursorの同時運用を避けた
  • [ ] Minimize Frictionから開始した
  • [ ] sensitive pathだけ強化した
  • [ ] XHR/fetchのcookie送信を確認した
  • [ ] challenge loopを監視する
  • [ ] conversionとsecurityを同時評価する
  • [ ] mode切替手順を演習した

一次情報