Cloudflare Client-Side Security、公開スキャナーが見逃した8件のペイロードを発見
Cloudflare Client-Side Securityは、4つのストアフロント・キャンペーンにまたがる8件の悪意あるペイロードを発見した。公開スキャンサービスでは警告がほとんど、あるいはまったく出ていなかったという。影響を受けたページは引き続き読み込まれ、商品を表示し、顧客の操作も処理していた。その通常どおりの体験の裏で、JavaScriptはアフィリエイト報酬の帰属をリダイレクトし、ネットワークリクエストを隠し、分析を妨害し、リモートコードへの経路を作り出していた。
Cloudflareは2026年9月16日にこの調査結果を公表した。その中心的な主張は、広く見られるセキュリティ上の前提に疑問を投げかける。スキャンが正常でも、ブラウザセッションが安全に動作しているとは限らない。Cloudflareが確認した時点で、7件のペイロードはVirusTotalに存在せず、urlscan.ioも8件すべてについて悪意ある判定を返していなかった。
この比較は重要だが、文脈も必要だ。VirusTotalとurlscan.ioは、送信されたファイル、URL、エンジン、観測可能な挙動に基づく有用なインテリジェンスを提供する。一方Cloudflareは、実際のウェブサイトトラフィック内でこれらのスクリプトに遭遇し、その内部構造を分析した。この食い違いは、成果物を一度だけ検査することと、実際のブラウザに到達するコードを継続的に監視することの間にあるカバレッジの差を示している。
4つのキャンペーンが通常のストアフロント・トラフィックを加盟店に不利な形で利用
Cloudflareの発見が重要なのは、これらのキャンペーンが必ずしもチェックアウトを壊したり、ウェブサイトを停止させたりせずに、収益オペレーションを攻撃していたためだ。
同社の4つのキャンペーンに関する調査結果は、アフィリエイト詐取、クリック操作、リモートコードの読み込み、分析の妨害、訪問者追跡を扱っている。Cloudflareによれば、自動化システムが人間のアナリストによる調査に先立ってペイロードを検出した。
最初の活動は、特定の期間にモバイル購入者を狙った。対象となる商品要素が表示されるのを待ち、購入者のクリックを横取りして、攻撃者が選んだページを別タブで開いた。その間、元のタブはアフィリエイト追跡ルートを経由してストアに戻された。
この迂回により、顧客を紹介していないアフィリエイトに成果が帰属する可能性がある。加盟店は不当なコミッションを支払うか、正当なパートナーへの成果付与を拒むことになり得る。ストアフロント自体は動作し続けるため、顧客は気づかない可能性がある。
Cloudflareはこの活動で、関連する5つのビルドを発見した。取得時に稼働していたのは2つで、3つは停止していた。稼働中の亜種は、デバイス種別、ローカル時刻、ブラウザ状態、商品の可用性、直近の実行状況を確認してから、目に見える動作を行っていた。
後期のバージョンでは、ウェブサイトスクリプトが利用できる永続的な保存領域であるブラウザのlocalStorageに、3日間のクールダウンを保存していた。一度作動すると、マルウェアはそのデバイス上で数日間沈黙を保つ。そのため、同じ訪問を繰り返すスキャナーでは異常が何も見えない可能性がある。
2番目の活動では、購入者のクリックすら必要としなかった。そのスクリプトは、画面外のiframeを通じてアフィリエイトリクエストを発行した。iframeとは、表示レイアウトの外側に隠された埋め込みページである。主要な手法が失敗した場合、隠しリンクが自らクリックされる可能性もあった。
コードは最初にIPジオロケーションサービスへ接続したが、返された地理情報は無視していた。そのリクエストが失敗すると、マルウェアは停止した。Cloudflareは、この挙動が意図的なサンドボックス回避なのか、残存したロジックなのかを判断できなかった。
3番目の活動はより広範だった。加盟店のHTMLに直接埋め込まれたスクリプトには、古い検索ハイジャック・モジュールと、有効なテレメトリおよびリモート読み込み機能が併存していた。ページ読み込み後、攻撃者が管理するサーバーから新たなJavaScriptを要求できた。
これはストアフロントのバックドアを生み出した。リモートサーバーは応答を変更できるため、初期スクリプトに最終的な攻撃動作を含める必要はなかった。Cloudflareは、攻撃者が実際にどの第2段階ペイロードを配信したかを判断できなかった。
4番目の活動は、有料キャンペーン経由で訪れるモバイル訪問者を狙った。9種類の分析・監視ツールを無効化しようとし、カスタマーサポートのインターフェースを抑止し、広告IDを置き換え、テレメトリを送信した。
このスクリプトは、ビューポート幅が477ピクセル未満かどうかを確認した。また、訪問者が最初に閲覧した2ページにおいて、特定のキャンペーンタグを探した。325件のIP部分文字列リストは、アナリストや自動化インフラに関連するネットワークを回避するのに使われていた。
これらの活動は、単一のドメイン、シグネチャ、収益化戦略を共有していなかった。共通していたのは選択的な実行だ。各スクリプトは、短時間の自動検査では再現しにくいブラウザ状態を待っていた。
正常なスキャン1回では決して十分ではなかった理由
主要な対立は、機械学習と既存のすべてのセキュリティ制御の対立ではなく、継続的なブラウザ可視性と特定時点でのスキャンの対立にある。
従来のスキャナーは有用だが限定的な問いに答える。このファイルは以前に誰かが送信したか。エンジンはそのシグネチャを認識するか。制御された訪問で観測可能な挙動は発生するか。マルウェアが本当のロジックを誰に見せるかを選ぶ場合、こうした問いの信頼性は低下する。
Cloudflareのある例は、urlscan.ioにほぼ2年半にわたり分類なしでインデックスされ続けていたと報告されている。そのより広範なマルウェアファミリーはすでに文書化されていたが、その特定のペイロードには同じような実用的なラベルが付与されていなかった。
静的クローラーはページを読み込み、ファイルを検査し、ネットワークトラフィックを記録できる。しかし、その結果はある時点における一つのブラウザ構成を表すにすぎない。ストアフロント・マルウェアは作動前に、時刻、デバイス、所在地、リファラー、Cookie、画面幅、セッション履歴をテストできる。
営業時間外のアフィリエイト・ハイジャッカーは、初期ページ読み込み後に生成される商品タイルを監視していた。これは、ページのドキュメント構造の変更を検出するブラウザ・インターフェースであるMutationObserverを使用していた。元のHTMLだけを取得するクローラーは、フックされた要素を見逃す可能性がある。
有料モバイル向けのクローキングはさらに進んでいた。企業ネットワーク、クラウドプロバイダー、ホスティング施設、VPN、プロキシ、Tor出口ノード、複数の地理的地域を拒否していた。これらのチェックは、研究者や自動化スキャナーが一般的に使う環境を不釣り合いに排除する。
ここでは不都合な逆転現象が生じる。企業ネットワークからの正常なデスクトップテストは、回避ロジックが機能している証拠になり得る。悪意ある分岐が調査者に対して実行されないため、加盟店には通常どおりの分析データが表示される。
これらのキャンペーンは、ウェブサイトの運用健全性が誤解を招き得る理由も示している。可用性監視はページが応答することを確認する。合成チェックアウトテストは取引が完了することを確認する。しかし、どちらの検査も、誰に成果が帰属するか、あるいはどのブラウザ接続が発生するかを必ずしも明らかにしない。
サーバー側ログもまた、部分的な視点しか提供しない。サードパーティ製スクリプトは、ページのドキュメントとブラウザコンテキストにアクセスして実行される。OWASPのサードパーティ製スクリプトのリスクには、変更管理の喪失、任意コード実行、機密データの漏えいが含まれる。
Cloudflareの証拠は、公開スキャナーを時代遅れにするものではない。送信済みの成果物、過去の観測、レピュテーションデータ、共有された侵害指標は、調査に不可欠であり続ける。むしろ今回の調査結果は、これらのシステムが受け取っていないコードや、発動しなかった挙動にはラベルを付けられないことを示している。
最も強力な防御態勢は、複数の視点を組み合わせるものだ。レピュテーションサービスは既知のインフラを特定できる。コード分析は意図を調べられる。ブラウザ・テレメトリは読み込まれたリソースや接続を明らかにできる。その上で人間のアナリストが、自動判定が運用上の文脈に合致するかを判断できる。
この多層モデルは、一度きりのスキャンを最終的な許可とみなすセキュリティチームに再考を迫る。また、タグマネージャーがセキュリティチームによる継続的なレビューをほとんど受けないコードを管理することが多いため、マーケティングおよびコマースチームにも再考を促す。
Cloudflare Client-Side Securityが回避的JavaScriptを読み取る仕組み
Cloudflare Client-Side Securityはまずコード構造に注目し、その後に言語モデルと人間によるレビューを利用して、不確実な検出結果を絞り込む。
Cloudflareの最前線分類器は、グラフニューラルネットワーク、すなわちGNNだ。この機械学習モデルは、接続された要素の関係を処理する。ここでの要素は、JavaScriptの抽象構文木から得られる。抽象構文木は、コードを生のテキストではなく構造化された操作として表現する。
この違いにより、モデルは表面的な変更を超えて分析できる。攻撃者は変数名を変更し、ファイルを最小化し、文字列を入れ替え、未使用の分岐を追加できる。こうした変更は見た目のテキストを変えるが、呼び出し、条件、ページイベント、ネットワークリクエストの関係性は維持される可能性がある。
Cloudflareによると、そのGNNは実トラフィック内で8件すべてのペイロードにフラグを付けた。同社は以前、より広範な検出アーキテクチャを、すべての判断を単一モデルが下す仕組みではなく、カスケードとして説明している。
GNNは疑わしい構造を捉えるよう調整されている。良性と判断したスクリプトはパイプラインを早期に離脱する。悪意がある可能性があるスクリプトは、Workers AIを通じて動作する小規模な言語モデルによる第2の評価を受ける。
この第2段階は、偽陽性の問題に対処する。正当な広告バンドル、ボット対策、トラッキングスクリプト、圧縮されたフレームワークは、悪意あるコードに似て見えることがある。コンテキストがなければ、難読化、動的実行、異例のネットワーク呼び出し、その他の疑わしいパターンを使用する可能性がある。
Cloudflareは以前の製品アップデートで、同社のシステムが毎日35億件のスクリプトを評価していると報告した。また、平均的なエンタープライズ・ゾーンでは約2,200件のユニークなスクリプトが公開されているとも述べた。同社によれば、その約3分の1は30日間で変更され得るという。
これらの数値はCloudflareによるものであり、今回のキャンペーン開示に関して独立監査を受けたものではない。それでも、運用上の課題を示している。偽陽性率が低くても、数十億件の評価に適用すれば管理不能になり得る。
最新の調査でCloudflareは、分析対象トラフィックのうち言語モデルによるレビュー段階に到達したのは0.3%未満だったとしている。そのモデルがGNNの判断を裏付けた場合、システムは顧客に警告した。
より複雑なサンプルには、さらに別の分析層が適用された。Cloudflareは約6つのファミリーのモデルを、独立した「教師」として使用した。各モデルは新しいセッションで同じスクリプトを検査し、制限されたJavaScript評価器にアクセスできた。
モデルは、良性、決済スキミング、その他のマルウェア、暗号資産マイニングという4つのラベルに投票した。Cloudflareは外部のモデル性能ランキングを用いて、その投票に重みを付けた。悪意ありとラベル付けされたスクリプト、または3分の2の多数を得られなかったスクリプトは、人間のレビュアーが検査した。
これは完全自律型のループではない。Cloudflareは、GNNトレーニングへのフィードバックが依然として一部手作業であることを認めている。同社はまた、隔離環境でより深い分析を行うため、Cloudflare Sandboxを追加する計画も示している。
このアプローチは、構造的分類、意味的レビュー、モデル間の不一致、アナリストの判断を組み合わせる。その利点は、言語モデルが何らかの形であらゆる攻撃を「理解」することではない。各段階が異なる失敗モードに対処する点にある。
GNNは大量のデータの中で構造的な類似性を認識できる。言語モデルは、奇妙だが正当なJavaScriptを除外できる。複数の教師モデルは不確実性を明らかにできる。アナリストは、自動シグナルが依然として懸念を示す、または判断が分かれる、より小さな集合を調査できる。
継続的な監視は、こうした判断に必要な文脈を提供する。Cloudflareのセキュリティドキュメントによれば、このサービスは訪問者に読み込まれるスクリプト、接続、Cookieを監視する。高度な機能には、悪意あるスクリプトの検出、コード変更アラート、コンテンツセキュリティルールが含まれる。
このアーキテクチャは、主な競争領域に直接対応する。ポイントインタイム型のツールは、選択されたサンプルやセッションを検査する。継続的なブラウザレポーティングは、実際の訪問を通じてリソースがどのように現れるかを記録し、選択的に動作するマルウェアが最終的に正体を現す可能性を高める。
ブラウザは収益システムの一部になった
これらの攻撃は、クライアントサイドのセキュリティが、決済データに加えてアトリビューション、分析、顧客アクセスも保護する必要があることを示している。
最初の2つのキャンペーンは、カード番号ではなくアフィリエイト経済を標的としていた。この違いは重要だ。多くのストアフロントのセキュリティプログラムは、最も強力な制御をチェックアウト周辺に集中させている。しかし、収益はカスタマージャーニーのより早い段階でも流出し得る。
アフィリエイトシステムは、どのパートナーに購入の成果を帰属させるかを決定する。攻撃者は、その判断を改ざんできれば取引を停止させる必要はない。不正なアトリビューションリクエストによって、正当な販売を不当なコミッションへと変えられる。
最初のキャンペーンにおけるデュアルタブの手口は、顧客のショッピングフローを維持していた。一方のタブで訪問者の操作を継続させ、もう一方で攻撃者のトラッキング経路を通過させた。この攻撃は、通常のナビゲーションイベントに見えることから利益を得ていた。
クリック不要型の亜種は、さらに目立たなかった。不可視のiframeが、意味のある顧客操作なしにアフィリエイトリクエストを発行できた。Cloudflareは自動化されたリクエストを確認したものの、それらが実際に支払済みのコミッションにつながったかどうかは立証していない。
この制約は明確にしておくべきだ。コードは意図と能力を示せても、実現した金銭的被害までは証明できない。実際の損失を測定するには、加盟店のアトリビューション記録、アフィリエイトアカウントのデータ、支払い履歴が必要になる。
有料モバイル向けクローカーは、別の事業資産である可観測性を狙っていた。標的は、有料検索、テキストキャンペーン、その他のタグ付けされたチャネルを通じて加盟店がすでに購入していたトラフィックだった。こうしたセッションが価値を持つのは、顧客獲得への支出によってストアへ誘導されていたからだ。
このマルウェアは、監視ツールやサポートツールを無効化しながら、分析識別子を置き換えようとした。成功すれば、キャンペーンレポーティングを改ざんし、正当なトラフィックが別の帰属先のものに見えるようにできた可能性がある。
また、チャットや問い合わせ用のコントロールも抑制した。異常に気付いた買い物客は、それを報告する最も容易な経路を失う可能性がある。その結果、加盟店はテレメトリーと顧客からの直接的なフィードバックの双方を失う。
Cloudflareのサンドボックス試験では、置換された分析スクリプトが読み込まれ、トラッキングビーコンを発信したことが確認された。しかし同社は、攻撃者が利用可能なテレメトリーを取得したことや、広告収益を横取りしたことまでは証明していない。
ストアフロントのバックドアは異なるリスクをもたらした。スクリプトが任意のリモートJavaScriptを読み込めるようになると、攻撃者の選択肢は観測されたモジュールに限定されなくなる。加盟店のHTMLを再び編集しなくても、後続の指示を変更できる。
この柔軟性は、インシデントの影響範囲の特定を複雑にする。目に見えるリダイレクトを1つ削除しても、攻撃者に他の能力がなかったとは確認できない。対応担当者は、最初の挿入経路、リモートエンドポイント、影響を受けたセッション、管理権限の侵害の有無を特定する必要がある。
Cloudflareは、そのスクリプトがどのように加盟店のHTMLへ入り込んだかを特定できなかった。侵害された認証情報、無許可のテンプレート変更、感染したテーマやプラグインを、確認済みの原因ではなく、考えられる経路として挙げている。
この不確実性は修復において重要だ。観測されたドメインをブロックすれば1つの配信経路は止められるが、元のアクセス経路が開いたまま残る可能性がある。持続的な対応には、認証情報の見直し、テンプレートの完全性チェック、依存関係の棚卸し、タグマネージャー権限の検証が必要になる。
業界はすでに、ブラウザを決済セキュリティ境界の一部として認識している。PCI Security Standards Councilの決済ページに関するガイダンスは、スクリプトの承認、完全性の検証、無許可の変更に対するページ監視に焦点を当てている。
Cloudflareのキャンペーンは、こうした取り組みを行う運用上の理由を広げている。ブラウザは単にチェックアウトフォームを描画するだけではない。マーケティング上の成果を帰属させ、行動を記録し、サポートツールを読み込み、どの外部サービスが顧客データを受け取るかを決定する。
したがって、セキュリティ、マーケティング、コマース、分析の各チームは、同じ攻撃対象領域を共有している。計測目的で承認されたマーケティングタグが配信経路になり得る。侵害されたテーマがコマンドチャネルになり得る。アトリビューションの仕組みが窃取の標的になり得る。
この重なりは組織的な圧力を生む。セキュリティチームにはブラウザ側の変更に対する可視性が必要であり、一方でマーケティングチームにはすべてのキャンペーンを停止させないレビュー工程が必要だ。難しい課題は、通常のストアフロント運用を機能不全に陥らせることなく、変化の速いスクリプトを統制することである。
Cloudflareの調査結果には慎重な解釈がなお必要だ
キャンペーンの証拠は継続的監視を支持するものの、すべての製品主張を独立して検証したり、加盟店の最終的な損失を定量化したりするものではない。
Cloudflareはサンプルを発見し、検出システムを運用し、技術分析を公開した。これにより同社は価値の高いテレメトリーに直接アクセスできる。同時に、中心的な性能比較が、高度な検出サービスを販売するベンダー自身によるものであることも意味する。
公開情報では8つのペイロードが示され、その動作が説明されているが、影響を受けた加盟店の身元は明かされていない。この判断は被害者を保護し、新たな標的リストの作成を避けるものだ。しかし、インシデントの金銭的・運用上の影響を独立して検証することも制限する。
Cloudflareは、同一条件下で自社システムとあらゆるスキャナーを比較した統制ベンチマークを公開していない。同社の証拠は、VirusTotalに7つのペイロードが存在せず、urlscan.ioが悪意ある判定を返さなかったことを示す。それは市場全体で優れた検出力を証明することよりも限定的だ。
取り込みと分類も異なる。受け取っていないファイルにラベルを付けることはできない。Cloudflareがスクリプトを観測できたのは、影響を受けたトラフィックがそのネットワークとブラウザレポーティングのワークフローを通過したためだ。このアクセス上の優位性は、モデル精度とは別のものである。
VirusTotalがすでに把握していた1つのペイロードは、単純な勝者・敗者の物語をさらに複雑にする。公開履歴からは、悪意ある判定がいつ付与されたかは分からなかった。そのため、利用可能な記録だけでは、どのシステムが最初にそれを特定したかを確立できない。
偽陰性には注意が必要だが、偽陽性も同様だ。未知のJavaScriptを過度に積極的にフラグ付けするシステムは、アナリストを圧倒したり、正当なコマースをブロックしたりする恐れがある。Cloudflareが追加の言語モデルを使う理由の一部は、無害なコードが構造的にマルウェアと似ることが多いためだ。
Cloudflareは以前、その第2段階を加えた後に偽陽性が大幅に減少したと報告している。これらの結果は、独立した査読付き評価ではなく、社内評価だった。顧客は、自社のスクリプト群とインシデント結果に照らしてアラート品質を判断すべきだ。
モデルパイプラインにも人間による選択が含まれる。どのスクリプトを次段階に進めるかは判断閾値が決める。プロンプティングは言語モデルのレビューを形作る。モデルランキングの重みは教師モデルの投票に影響を与える。人間のアナリストは選択された事例を判断し、ラベルをトレーニングにフィードバックする。
こうした選択は調査結果を無効にするものではない。「AIが検出した」という説明だけでは不十分である理由を示している。検出品質は、テレメトリー、モデル設計、閾値、アナリストレビュー、そしてアラート後の対応プロセスに依存する。
Content Security Policy、すなわちCSPも、依然として重要な層である。CSPは、ページが許可すべきリソースや接続をブラウザに指示する。CSPレポーティングリファレンスで説明されているように、レポート専用モードでは、強制適用の前に違反を収集できる。
しかし、レポーティングだけでは悪意あるコードをブロックできない。許可リストが過度に広い場合、侵害されたベンダーを許してしまう可能性がある。すでに信頼されているオリジンからの直接挿入も、単純なドメイン制限を回避し得る。
厳格な強制適用には、それ自体運用コストが伴う。現代のストアフロントは、広告、実験、決済、パーソナライゼーション、サポート、分析のサービスを読み込む。これらのドメインやコードは頻繁に変更される可能性があり、狭いポリシーの維持を難しくする。
Subresource Integrityは、リモートから読み込まれるファイルが承認済みのハッシュと一致することを検証できる。安定したリソースに最も適している。一方、ベンダーが固定されたバージョン管理済みファイルを公開せずにスクリプトを意図的に変更する場合には、より難しくなる。
実務上の結論は、1つの制御が他のすべてに取って代わるということではない。継続的な観測、スクリプトのインベントリ、完全性チェック、CSP、レピュテーションインテリジェンス、インシデント対応は、それぞれ異なる穴を補う。
Cloudflareの最も強い証拠は、自社のテレメトリー内で見つかった選択的マルウェアに関するものだ。未証明の領域は、実現した収益窃取、第2段階の活動、初期アクセス、観測されていない攻撃に対する性能に関わる。こうした境界は、購入や導入の判断を形作るべきである。
継続的検出が成果を出すかを示す3つのシグナル
次の試金石は、Cloudflareがこれらの発見を再現可能な検出、より明確な証拠、より迅速な加盟店対応へと転換できるかどうかだ。
第1のシグナルは、より広範な技術的検証である。セキュリティ研究者は、公開されたインジケーターを用いて、他の環境で関連するインフラやコードを探すことができる。追加の発見があれば、4つのオペレーションが孤立した侵害だったのか、より広いキャンペーンの一部だったのかが示される。
独立した分析では、スクリプトのアトリビューション動作、リモート読み込み経路、解析妨害のゲートも確認できる。研究者がこれらの発見を再現すれば、Cloudflareの解釈はより強固になる。無害な説明や異なる結果が見つかれば、信頼の範囲は狭めるべきだ。
第2のシグナルは、Cloudflareがサンドボックスのワークフローを拡張した後の検出品質である。隔離されたブラウザ実行は、本番システムを保護しながらペイロードの動作についてより強い証拠を提供できる。また、実行時テストでどのモデルの疑いが成り立たないかも明らかにできる。
有用な報告には、アラート精度、アナリストが確認した攻撃、オーバーライド、見逃し事例が含まれる。繰り返しの実行は性能測定を歪める可能性があるため、集計値では分析対象のトラフィックとユニークなスクリプトを分けるべきだ。
顧客は、アラート総数だけでなく説明の品質にも注目すべきだ。有用な警告は、トリガーとなったコードパス、観測された接続、影響を受けたページ、関連するブラウザの状態を特定する必要がある。一般的な悪意あるラベルでは、封じ込めの指針を示さないまま作業だけが増える。
第3のシグナルは、加盟店の対応時間である。技術的に正しいアラートでも、見過ごされたり、担当者が不明だったり、連携した調査を開始できなかったりすれば、その価値は限定的だ。ストアフロントのチームには、ブラウザ上の証拠から封じ込めへ至る経路が必要である。
そのプロセスでは、タグを無効化し、認証情報を無効化し、テンプレートを復元し、エンドポイントをブロックし、その後に分析を検証できる担当者を特定すべきだ。また、コミッション、顧客データ、キャンペーン測定値に影響があったかを判断するための証拠も保存する必要がある。
継続的監視は、最初の悪意ある実行から除去成功までの間隔を短縮できるとき、より説得力を持つ。チームがアラートを受け取っても、実際の侵害と日常的なスクリプト変更を区別できない場合、その説得力は低下する。
ストア所有者は、直接的な問いを投げかけるべきだ。現在の制御で、実際の顧客にどのJavaScriptが届いたのか、そのコードが何をしたのか、どこへ接続したのかを説明できるだろうか。クリーンなスキャンだけでは、この3つすべてには答えられない。
Cloudflare Client-Side Securityは、技術的に詳細なベンダー開示に裏付けられた、こうした可視性を実現するための一つのアプローチを提供します。この証拠は注目に値しますが、導入を検討する企業は、自社のストアフロント環境でアラートの品質と対応フローとの統合性を引き続き検証すべきです。
直ちに取るべき行動は、製品の購入にとどまりません。ブラウザスクリプトを棚卸しし、タグマネージャーの権限を見直し、レポートポリシーをテストし、クライアントサイドのアラートの責任者を明確にしてください。そのうえで、通常の可用性スキャンや脆弱性スキャンでは見逃される挙動を、これらの対策が検出できるかを測定します。
