フォームは正常でも、送信後に発生したリクエストを見たことがないなら
登録コンバージョンを測定するために広告ピクセルを追加し、問い合わせプロセスを改善するためにセッションリプレイを有効にします。フォームも正常に送信され、イベントも蓄積されるため、問題がないように見えるでしょう。しかし、メールアドレスとパスワードを入力した瞬間にどの外部リクエストが発生するかを確認していなければ、フォームが動作するかどうかだけでデータ送信の範囲まで判断することはできません。
セキュリティ企業Melurnaのテストによると、Klaviyoの登録フォームは少なくとも2024年2月から2025年11月まで誤って構成されていました。メールアドレス・パスワード・会社名・Webサイトのアドレス・電話番号が、ページに埋め込まれたFacebook、Google、HubSpot、Microsoft、LinkedIn、Xなどの外部トラッキング企業と共有され得る状態でした。ただし、公開資料では、どのコードや設定が正確な原因だったのか、各社がどのフィールドを実際に受信・保存したのかは明らかにされていませんでした。
Klaviyoは問題を修正し、影響を受けた利用者に通知したと述べています。既知の影響人数は「即時に利用可能なアクティブログ」を基準に200人未満でしたが、ログ保存期間が公開されていないため、全期間の影響規模として一般化することはできません。
最初の確認はネットワーク監査から始めます
別のサービスへの登録やAPI認証は必要ありません。Chromeと内蔵DevTools、そして組織が所有する、または明示的にテストを許可されたフォームがあれば始められます。以下の入力値は形式を示すための例です。実際の顧客情報や他のアカウントで使用しているパスワードは入力せず、組織が管理するテスト用アドレスとフォームの検証ルールに合う値に置き換えてください。
テスト値の例
- メールアドレス: qa+form-audit-20260907@example.test
- ダミーパスワード: WR-AUDIT-ONLY-9f3K!2
example.testが実際のフォームのメール認証を通過できない場合は、組織が管理する受信可能なテスト用アドレスを使用してください。送信が完了しなければ、送信後に実行されるタグも評価できません。
- 公式手順と準備状況を確認します。
Chrome Network公式ドキュメントのリクエスト記録、Preserve log、リクエスト検索の箇所を開いておいてください。Chrome以外にインストールするツールやログインするサービスはありません。対象フォーム、同意状態、ログイン状況、地域条件を再現する権限も確認します。 - 記録を消去してPreserve logを有効にします。
フォームをChromeで開いた後、DevToolsのNetworkパネルに移動します。録画表示が有効か確認し、既存のリクエストを消去してからPreserve logを選択してください。この設定により、送信後に別ページへ移動しても前ページのリクエストが残ります。ただし、DevToolsを開く前に完了したリクエストまで遡って記録することはありません。 - 固有のテスト値で送信を完了します。
組織が管理するテスト用メールアドレスと、実際のサービスで再利用しないダミーパスワードを入力します。送信ボタンを押した後、成功画面または成功レスポンスまで確認し、時刻と同意・ログイン・地域条件を記録してください。検証エラーが出た場合、そのシナリオは完了したテストとして数えません。 - 通常のFilterではなくSearchタブを開きます。
Networkパネルにフォーカスした状態で、macOSではCommand+F、Windows・LinuxではControl+Fを押してください。右側に開いたSearchタブにテスト用メールアドレス・電話番号・ダミーパスワードを一つずつ入力し、Enterを押します。画面上部のFilter入力欄はドメインやメソッドなどのリクエスト属性を絞り込む場所であり、Payload文字列全体を検索する検索欄ではありません。 - 一致したリクエストの宛先と発生経路を記録します。
各検索結果をクリックして宛先URLとHeaders·Payload·Responseを確認し、リクエスト一覧のInitiatorでどのスクリプトがリクエストを作成したか追跡してください。HARには認証トークンや個人情報が含まれる可能性があるため、一般的なメッセンジャーや公開業務リポジトリにアップロードしません。 - 原文がなくても第三者リクエストとタグ設定を照合します。
送信前後に新たに発生した外部ドメインへのリクエストを確認し、GTM・広告タグ・CMPで自動収集、ユーザー提供データ、CSSセレクタ、ハッシュ化機能が有効か確認してください。Google Adsの拡張コンバージョンでは、メールアドレス・氏名・住所・電話番号などのファーストパーティデータを収集し、ハッシュ化した形でGoogleへ送信できるため、原文検索だけでは見つからない可能性があります。 - 承認状況を判断し、送信経路を制限します。
原文または確認可能な変換値が見つかった場合は、宛先、キャンペーン目的、同意条件、適用製品、内部承認を照合してください。ハッシュ値であることだけを理由に漏えいと断定することはできませんが、Google Analyticsへ向かうメールアドレス・個人の電話番号などのPIIは送信前に削除する必要があります。URL・ページタイトル・フォーム入力値に混在するPIIも点検対象です。 - 修正後、同じ条件で再度送信します。
Preserve logの設定から同じように繰り返してください。送信の成功が記録され、未承認の宛先でテスト値の原文または確認可能な変換値が見つからず、タグ設定にもそのフィールドを収集する未承認の経路がないとき、そのシナリオは最初の点検を通過したと記録します。
検索結果がないことは、ただちに安全を意味しません。
値が正規化・ハッシュ化・エンコードされたり、複数フィールドに分割されたりすると、原文検索に表示されない場合があります。タグ設定を確認する権限がない場合は「未検出」と記録し、完全な判断は保留してください。
dataLayerは送信リストであり、セキュリティ境界ではありません
同じページで実行される第三者JavaScriptは、DOMで利用可能なデータを読み取ることができます。許可した値だけをdataLayerに入れても、通常の第三者コードによるDOMアクセスが自動的に遮断されるわけではありません。実際の範囲は、iframeの分離、サンドボックス、タグマネージャーの設定によって異なります。
ブラウザから該当スクリプトを削除できるなら、ホストが値を検証した後、必要なデータだけをサーバー側の送信経路で送る構成を検討できます。クライアントタグを維持する必要がある場合は、不要なDOM変数とCustom HTMLを減らし、テンプレート権限・セレクタ・自動収集の範囲を制限してください。
GTMでは、コンテナ権限はRead・Edit・Approve・Publishに分かれます。タグを変更する人と本番に公開する人を分けつつ、権限分離だけではすでにデプロイされたタグの収集範囲を検証できないことも覚えておく必要があります。
セッションリプレイでは現在の設定と変更時点を確認します
セッションリプレイツールは、製品と設定によってマスキング範囲が異なります。Microsoft Clarityは現在、すべてのマスキングモードで入力ボックスとドロップダウンをマスクし、デフォルトのBalancedモードでは数字とメールアドレスも機密コンテンツとして分類します。
Clarityを使用している場合は、Settings → Maskingで現在のモードを確認し、さらに隠すコンテナをCSSセレクタまたはdata-clarity-mask属性で指定してください。変更は過去の記録に遡及せず、新しい記録に反映されるまで最大1時間かかる場合があります。Clarityのマスキングによって、他の広告・分析タグの送信まで防げるわけでもありません。
新しいタグが追加されるたびに同じ質問を繰り返してください
トラッキング技術による機密情報の共有は、Klaviyoだけの単発事例ではありません。米国FTCは、GoodRxが処方薬や健康状態などの情報をFacebookやGoogleなどの広告プラットフォームと何年にもわたり共有していたと主張しました。 Princetonの研究者も、セッションリプレイが観察された8,000サイトのリストと、Walgreensの処方情報、Gradescopeの学生情報の事例を公開しました。
各事例の技術構成、データ種類、期間、法的地位はそれぞれ異なります。同じ欠陥や一つの被害規模としてまとめることはできません。繰り返される運用上の問題は、新しいタグが追加された後に、実際の送信フィールドと実行条件を再検査したかです。
キャンペーン変更記録にあわせて残す項目
- タグの依頼者と業務目的
- 実行されるフォームと同意・ログイン・地域条件
- 外部宛先と承認済みの原文・正規化・ハッシュフィールド
- 送信成功の有無とNetwork Searchの結果
- 自動収集・セレクタ・ユーザー提供データの設定
- 停止・修正・公開の権限を持つ担当者
実際の個人情報が未承認の宛先へ送信されていることを発見した場合、再現の範囲をむやみに広げないでください。まずタグまたは送信経路を制限し、証拠へのアクセスを統制したうえで、セキュリティ・プライバシー・法務担当者とインシデント対応および通知の必要性を検討する必要があります。
さらに深く調べるなら
Network features referenceでは、ページ遷移間でのリクエスト保持、Command/Ctrl+Fで開くSearchタブ、Headers·Payload·Initiatorの確認方法を参照できます。 developer.chrome.com
Third Party Javascript Managementは、第三者コードがDOMデータにアクセスする仕組みと、クライアント側・サーバー側の送信方式の違いを点検する際に役立ちます。 cheatsheetseries.owasp.org
About enhanced conversions for webでは、ユーザー提供データが正規化・ハッシュ化されて送信され得るGoogle Ads機能の範囲を確認できます。 support.google.com
