Cloudflareのブラウザ整合性チェックとは？仕組みと使い方を理解する
Cloudflareの管理画面で「ブラウザ整合性チェック(Browser Integrity Check)」という項目を見たことはありませんか？デフォルトで有効になっているこの機能ですが、実際に何をチェックしているのか、いつオンにすべきか、よく分からないまま使っている方も多いのではないでしょうか。
今回は、ブラウザ整合性チェックの仕組みと、実際の運用における注意点について解説します。
ブラウザ整合性チェックが具体的に何を検証しているのか
ブラウザ整合性チェック(BIC)は、スパマーや悪意のあるボットが悪用しがちなHTTPヘッダーのパターンを検出し、不審なリクエストをブロックまたはチャレンジする機能です。
User-Agentの検証
この機能の中心となるのが、User-Agentヘッダーの検証です。User-Agentヘッダーが存在しないリクエスト、または非標準的なUser-Agentを使用しているリクエストに対してチャレンジを行います。通常のブラウザは必ずUser-Agentヘッダーを送信するため、これが欠けている、または不自然な場合は、自動化されたボットやスクレイパーの可能性が高いと判断されます。
Cloudflareは悪意があると判断したUser-Agentのリストを内部で管理しており、それに基づいてリクエストをブロックします。ただし、このリストの詳細は公開されていません。これは、攻撃者がこの情報を利用して検知を回避することを防ぐためです。
HTTPヘッダーの整合性確認
User-Agentだけでなく、スパマーが頻繁に悪用する一般的なHTTPヘッダーのパターンもチェック対象となります。正規のブラウザが送信するヘッダーと比較して、不自然な組み合わせや欠落がある場合に検知される仕組みです。
加えて、クローラーやスクレイピングツール、自動化スクリプトなど、既知の悪意のあるボットが使用する特徴的なパターンとの照合も行われます。
どういう場合にオンにすべきか/オフにすべきか
ブラウザ整合性チェックはデフォルトで有効になっていますが、すべてのケースで適切というわけではありません。サイトの性質や想定されるアクセスパターンによって、オンオフを判断する必要があります。
オンのままで問題ないケース
一般的な公開Webサイトで、通常のブラウザからのアクセスのみを想定している場合は、基本的にオンのままで問題ありません。コメント欄やフォームへのスパム投稿、スクレイピング攻撃が頻繁に発生している環境では、BICは有効な防御手段となります。また、著作権で保護されたコンテンツや、無断転載を防ぎたいページなど、コンテンツ保護が必要な場合にも役立ちます。
オフにすべきケース
一方で、APIエンドポイントに対しては注意が必要です。
APIトラフィックに対してはBICを無効にすることが推奨されています。APIクライアントは通常、標準的なブラウザのUser-Agentを送信しないため、正当なリクエストがブロックされる可能性があるためです。
同様に、負荷テストツール(Azure DevOps、JMeterなど)からのリクエストはBICによってブロックされることがありますので、テスト中は一時的に無効化する必要があります。特定のIPアドレスや社内ネットワークからのアクセスのみを想定している社内システムや管理画面では、BICは不要でしょう。また、外部サービスからのWebhook通知を受け取るURLでは、BICが誤って通知をブロックする可能性があるため、こちらも無効化を検討すべきです。
部分的に無効化する方法
すべてをオフにする必要はありません。カスタムルールでスキップアクションを使用することで、特定のパスやリクエストに対してのみBICを無効化できます。例えば、/api/* 配下のみBICをオフにしたい場合は、カスタムルールを作成して選択的に無効化できます。
誤検知のリスクや実際の動作例
ブラウザ整合性チェックは便利な機能ですが、誤検知(False Positive)のリスクも存在します。
マイナーなブラウザでの問題
Waterfox、Pale Moonなどのマイナーブラウザを使用しているユーザーが、リダイレクトループに陥ったり、アクセスをブロックされたりすることがあります。Cloudflareの検証対象は主に主要な3大ブラウザ(Chrome/Edge、Firefox、Safari)であるため、それ以外のブラウザは非標準と判断されやすい傾向にあります。
また、ブラウザの情報を偽装するプライバシー拡張機能やプライバシー重視の設定を使用していると、Cloudflareのチェックに引っかかり、ボットとして扱われる可能性があります。
特定の文字列を含むUser-Agentの問題
興味深い事例として、過去にはUser-Agentヘッダーに「diamond」という単語が含まれているだけで、すべてのリクエストが403エラーになるケースがありました。これはWordPressサイトのプラグインが使用するUser-Agentに「bluediamond.com」というドメインが含まれていたために発生しました。このような予期しないブロックは、Cloudflareのブロックリストに特定のキーワードが含まれていることが原因です。
WordPress環境での誤検知
WordPress環境では特に注意が必要です。WordPressがサーバー側のリクエストに設定するUser-Agent形式(WordPress/<version>; <site-url>)が、BICによってブロックされることがあります。特にWP-CronやプラグインのREST APIリクエストが影響を受けやすく、プラグインが正常に動作しなくなる可能性があります。
トラブルシューティングの方法
誤検知が発生した場合、まずはSecurity > Overview でイベントログを確認しましょう。
Activity Logの「Service」列に「Browser Integrity Check」と表示されているか確認します。
問題のあるUser-Agentが特定できた場合は、そのUser-AgentをBypassするファイアウォールルールを作成することで、WAFをスキップさせることができます。
社内IPや特定のクライアントからのアクセスであれば、IP Access Rulesで許可リストに追加する方法も有効です。
特定のURLパターンに対してのみBICを無効化したい場合は、Page Ruleを使用できます(ただし、新しいアーキテクチャではカスタムルールの使用が推奨されています)。
まとめ
ブラウザ整合性チェックは、スパムやボット攻撃からサイトを守る有効な機能ですが、すべてのケースに適しているわけではありません。
一般的な公開サイトではデフォルトのオンのままで問題ありませんが、APIエンドポイントやWebhook受信URLでは無効化を検討すべきです。
誤検知が発生した場合は、カスタムルールで選択的にBypassすることで対応できます。
適切に設定することで、セキュリティとユーザビリティのバランスを保つことができます。
自社のサイトやアプリケーションの特性に合わせて、ブラウザ整合性チェックの設定を見直してみてください。