Client-side security(クライアントサイド セキュリティ）とは何か？

これまでWAF、DDoS対策、Bot対策などは、すべてインターネットから自社のWebサーバーに向かって届く攻撃を、入口で食い止めるための防御策でした。

しかし、これらのセキュリティ対策を100%完璧に固めていたとしても、残る深刻なセキュリティリスク ーそれがユーザーのブラウザー側（クライアントサイド）で発生する攻撃です。

現在のWebサイト、特にECサイトやマーケティングサイトでは、アクセス解析、広告計測タグ、チャットツール、SNS連携、決済モジュールなど、数多くの外部JavaScript（サードパーティスクリプト）が動いています。もし、これらの外部サービスやスクリプトが攻撃者によって改ざんされたらどうなるでしょうか。自社のWebサーバーは一切攻撃されていなくても、ユーザーのブラウザー上で悪意あるコードが実行され、入力された個人情報やクレジットカード情報が盗み取られてしまう危険にさらされます。

こうしたブラウザー側のリスクを監視、制御するために提供されているのが、Cloudflareの「Client-side security」です。従来は「Page Shield」と呼ばれていましたが、Cloudflareは2026年3月に、名称をPage ShieldからClient-side securityに変更しました。

ここでは、WAFでは防げないブラウザー側の脅威と、Client-side securityによる保護の仕組みについて解説します。

自社のサーバーが無傷でも情報は漏洩する!?

現代のWebサイトは、自社で書いたコードだけで動いているわけではありません。ECサイトを例に挙げると、1つのページ内に多様なJavaScriptプログラムが読み込まれ、必要に応じて動作しています。

• アクセス解析ツール（Google Analytics等）
• 広告効果測定、リターゲティングタグ
• タグマネージャー（GTM等）
• 接客チャットやレコメンドエンジン
• 決済処理スクリプト

問題は、これらのスクリプトの多くが、外部のサーバーからブラウザーへ直接読み込まれていることです。万が一、提供元の外部サーバーや配信ネットワークがサイバー攻撃を受けてスクリプトが改ざんされた場合、ユーザーが自社サイトにアクセスした瞬間、改ざんされた悪意あるコードが利用者のブラウザー上で実行されてしまいます。

これを「クライアントサイドのサプライチェーン攻撃」と呼びます。自社のサーバーをWAFなどによってどれだけ強固に守っていても、ブラウザーと外部サービスを結ぶ通信ルート、いわば自社サーバーの預かり知らないところから、攻撃の種が侵入してくる可能性があるのです。

出典： Cloudflare Docs: Client-side security

守る場所が違う、WAFとClient-side security

Client-side securityを理解する上で最も重要なのは、WAFとの役割、しくみの違いです。WAFの復習も兼ねて、整理しましょう。

• WAF（Web Application Firewall）
  • 不特定のユーザーから自社サーバーに入ってくる通信リクエストを検査し、SQLインジェクションなどの攻撃を遮断（入口の防御）
• Client-side security（旧Page Shield）
  • 自社サイトから正当なユーザーのブラウザーにページが届いた後、ブラウザー上で実行されるスクリプトや、そこから外部へ送られる通信を監視（ブラウザー内部、出口の監視）

両者はもちろん競合するものではありません。Webサイトの「表のドア」を守るのがWAF、ブラウザー内の動作を監視するのがClient-side securityです。両者は異なる領域を、異なる方法で守る相補的な関係にあります。

代表的な脅威： Webスキミング（Magecart）の怖さ

クライアントサイド攻撃の代表例が「Webスキミング（オンラインスキミング）」です。攻撃グループの名称から「Magecart（メイジカート）」と呼ばれることもあります。

ECサイトの購入画面や決済ページにおいて、改ざんされたJavaScriptが挿入され、実行されると、ユーザーがフォームに入力した「氏名」、「住所」、「電話番号」、「クレジットカード番号」、「セキュリティコード」などが、通常の決済処理とは別に、攻撃者の用意した外部サーバーへ、裏でこっそり送信されてしまうことがあります。

Webスキミングの恐ろしい点は、ユーザーからも、サーバーの運営者からも極めて発見しにくいことです。それは、以下に挙げるような理由によるものです。

• Webサイトの見た目やURL、鍵マーク（🔒）は正常なまま変わらない
• 通常の決済処理もそのまま問題なく完了するため、購入客も異常に気づかない
• 自社のWebサーバーのログには不正アクセスの形跡が残らない

個人情報の漏洩、悪用被害の報告を受けて初めて発覚するケースが多く、企業の信頼に壊滅的な打撃を与える可能性のある攻撃として、世界中で警戒が高まっています。

Webスキミングの可視化から制御へ至る段階的なアプローチ

Client-side securityの基本運用は、いきなりスクリプトの実行を強力にブロックすることではありません。以下のようなステップで、自社サイトの現状を把握することから始め、被害を抑止するところまで進めます。

1. 可視化とスクリプトの棚卸し

自社サイトの各ページで「どんなJavaScriptが読み込まれ、どこに通信しているか」を、Client-side securityが自動的に検出、一覧化します。これにより、「過去に導入して放置されている不要なタグ」、「担当者が把握していない広告スクリプト」、「見覚えのない不審な外部通信」などを洗い出します。

2. コード変化と悪意の自動検知（Advanced機能）

AIや機械学習を活用し、スクリプトのURLやコード内容、配信元ドメインなどを継続的にスキャンします。昨日まで正常だったJavaScriptの内容が突然変更された場合や、悪意ある振る舞いが検知された際には、即座にアラートを発します。

3. Content Security Rulesによる読み込み制限

ブラウザー標準の安全規格である「CSP（Content Security Policy）」の仕組みを利用して、「このページで読み込みを許可する外部ドメイン」を制限します。最初は「Log（記録）モード」でテストし、正常な通信に影響がないことを確認してから制限を適用します。

出典： Cloudflare Docs: Monitor resources and cookies

出典： Cloudflare Docs: Malicious script and connection detection

出典： Cloudflare Docs: Content security rules

ECサイトにおける「PCI DSS v4.0.1」対応との関係

Client-side securityが特に強く求められているのが、クレジットカード情報を扱うECサイトです。クレジットカード業界の国際セキュリティ基準である「PCI DSS v4.0.1」では、決済ページにおけるクライアントサイドのセキュリティ要件が、以下のように明確に強化されました。

• 要件6.4.3： 決済ページで実行されるすべてのスクリプトの承認と管理
• 要件11.6.1： 決済ページの改ざんや不審なスクリプト変更の継続的な検知

Cloudflare Client-side securityは、これらのPCI DSS要件に対応するための監視、管理基盤として機能します。ただし、ツールを導入するだけで完全準拠が保証されるわけではありません。個別の運用確認が必要です。

出典： Cloudflare Docs: Client-side security and PCI DSS compliance

他社のクライアントサイド保護機能の概要

ブラウザー側の保護機能は、Cloudflare以外の主要セキュリティベンダーからも提供されています。２つ例を挙げておきましょう。

• Akamai（Client-Side Protection & Compliance）： 高度な行動分析により、ブラウザ上のスクリプトの不正動作や情報窃取を検知し、PCI DSS準拠を支援
• Imperva（Client-Side Protection）： JavaScriptの自動可視化と制御を行い、Webスキミングやサードパーティリスクを防止

こうしたものの導入を検討する際には、自社がすでに利用しているWebセキュリティ基盤（CDNやWAF）と統合して一元管理できるかどうかが、重要なポイントとなるでしょう。

DOMOの視点

外部JavaScriptの棚卸しと、継続的な監視体制を構築する

DOMOとしてClient-side securityの導入を検討する際、最初に確認するのはセキュリティ機能の設定ではありません。「自社サイトで今、どんな外部タグやJavaScriptが動いているか把握できていますか？」という問いかけです。

マーケティングの施策や広告運用を重ねる中で、アクセス解析、ヒートマップ、チャット、SNSボタンなどのタグは次々と追加されます。しかし、担当者の変更や制作会社の交代によって、数年後には「何のために入っているのか誰も知らないタグ」が残ってしまうケースがよくあります。

セキュリティの観点から言えば、外部タグは単なる「マーケティングのための便利な設定」ではなく、「ユーザーのブラウザ上で動く外部プログラム」そのものなのです。まず、そのことをはっきりと意識した上で、次のようなステップによる対応を検討します。

1. 把握する： ページ内で動作するスクリプトを一覧化する
2. 整理する： 不要なタグを削除し、必要性を確認する
3. 監視する： コードの不審な書き換えを検知する
4. 制御する： 許可された通信先のみをCSP等で制限する

悪意あるJavaScriptを防ぐことはもちろん、自社サイトの「健全なタグ管理体制」を作り上げることこそが、DOMOが提唱するクライアントサイド・セキュリティの基本設計です。

まとめ

Client-side security（旧称Page Shield）は、ユーザーのブラウザー上で動作するJavaScriptや外部通信を監視し、Webスキミングなどの改ざんリスクを防ぐ機能です。

WAFでは防げない領域を守るもので、ユーザーのブラウザから外部へ出ていく通信を可視化して保護します。それにより、Webスキミング（Magecart）を防ぎ、ECサイトの決済ページなどで、外部スクリプトの改ざんによるクレジットカード情報や個人情報の盗難を防止する効果を発揮します。

導入にあたっては、タグや通信の「棚卸し」を行い、ログ確認を経て安全に制御ルールを適用するようにします。

覚えておきたい用語

• Page Shield： Cloudflareのクライアントサイド保護機能の旧名称（2026年3月からClient-side securityへ名称変更）
• Client-side security： Webページ上で動くスクリプトや外部通信などを監視・制御するCloudflareの機能
• JavaScript： Webサイトに動きや処理を加えるためのプログラム
• サプライチェーン攻撃： 外部サービスやソフトウェアなどを経由して攻撃する手法
• Webスキミング： Webページへ入力された決済情報などを悪意あるコードで盗み取る攻撃
• Magecart： ECサイトなどのJavaScriptを悪用して決済情報を盗む攻撃の総称
• CSP： Webページが読み込んでよいスクリプトや通信先などを指定する仕組み
• PCI DSS： クレジットカード情報を安全に取り扱うための国際的なセキュリティ基準