外部スクリプトの棚卸しは、依存関係スキャンでは終わらない｜出荷したコードとブラウザが実行するコードのずれ

外部スクリプトの棚卸しは、依存関係スキャンでは終わらない｜出荷したコードとブラウザが実行するコードのずれ

自社サイトの安全性を確認するとき、依存関係のスキャン結果を見て「既知の問題はなし」と判断することがあります。使っているライブラリに脆弱性が報告されていないかを機械的に調べられるので、確認した感覚も得やすい方法です。

ただ、このスキャンが見ているのは自社が出荷したコードの一覧です。サイトの訪問者のブラウザで実際に動くコードには、アクセス解析、広告、チャット、2つの案を比べる検証用のツールなど、外部から読み込むスクリプトも含まれます。この2つは同じ集合ではありません。

この記事では、2026年9月18日にThe Hacker Newsに掲載されたベンダー寄稿記事（寄稿元は、CSPの報告を収集するサービスを提供するReport URI）の指摘を材料に、2つの一覧がどこでずれるかを整理します。そのうえで、CSPの報告専用モードを「守る道具」の前に「測る道具」として入れる手順を示します。

30秒で要点

• 依存関係スキャンやソフトウェア構成分析（SCA）が調べるのは、自社が構築して出荷するもの。外部から読み込むスクリプトは対象外
• 外部スクリプトは、訪問者のブラウザが自社の運用していないサーバーから、ページが表示されるたびに取得する
• 応答は地域やブラウザの種類などで変わりうるので、1回取得して中身を見ても安全の確認にならない
• 外部スクリプトは自社のコードと同じ権限で動き、入力中のフォームの値やcookieを読み、外部に送信できる
• CSPの報告専用モードは何も止めずに「読み込まれたもの」を報告させられる。まず棚卸しの手段として使える（筆者の判断）

所有者の変わったドメインから、スクリプトが配られ続ける

寄稿記事が冒頭で挙げている事例から見ていきます。

2025年7月、数年前に事業を終えたCDNが手放したドメインを、第三者が登録しました。新しい所有者はドメイン全体に「どんなホスト名でも自分のサーバーに向ける」DNS設定（ワイルドカードDNS）をしており、配下の任意の名前がその人物の管理するサーバーにつながる状態だといいます。寄稿記事によれば、このドメイン配下のホスト名への固定の参照を、数千のWebサイト・コードリポジトリ・ドキュメントが今も持っています（件数の調査方法は示されていません）。

寄稿記事は先行事例として、2024年6月の polyfill.io の件も挙げています。11万を超えるサイトに埋め込まれていたJavaScriptの配布元ドメインの所有者が変わり、モバイルの訪問者に条件付きでリダイレクトを配信し始めたというものです。寄稿記事は、これらのサイトはハッキングされたのではなく、数年前に script タグで読み込み先を外部に委ねたまま見直していなかった、と書いています。

どちらの事例でも、サイト側のコードは1行も変わっていません。変わったのは、そのコードが指している先です。

出荷したコードとブラウザが実行するコードは、3点でずれる

寄稿記事の指摘を、筆者の整理で3つに分けます。

1. 取得のタイミングがずれる。依存関係スキャンは、ビルドや出荷の時点のコードを調べます。外部スクリプトは、ページが表示されるたびに取得されます。スキャンした日に問題がなくても、翌日に配信元の中身が変われば、訪問者が実行するものは変わります。

2. 取得する主体がずれる。自社のコードは自社のサーバーから配信されます。外部スクリプトを取得するのは訪問者のブラウザで、取得先は自社が運用していないサーバーです。自社のサーバーのログや構成管理には、その中身が残りません。

3. 応答の中身がずれる。寄稿記事は、外部スクリプトの応答は地域、ブラウザの種類（ユーザーエージェント）、参照元、時刻、セッションによって変わりうると指摘しています。データセンターのIPアドレスから1回だけ取得する調査用のプログラムには、問題のない版しか見せないことができる、というわけです。

この3点が重なると、「スキャンで問題なし」「URLを開いて中身を確認済み」という2つの確認を両方済ませても、訪問者が今日実行したコードについては何も分かっていないことになります。

外部スクリプトは、自社のコードと同じことができる

ずれがあっても、外部スクリプトにできることが限られていれば影響は小さいはずです。しかし寄稿記事は、外部スクリプトはファーストパーティ（自社）のコードと同じ権限を持つと書いています。

• ページの中身（DOM）を読む
• 入力中のフォームの値を1文字ずつ読む
• cookie とブラウザ内の保存領域（localStorage）を読む
• 任意の宛先へ通信する

つまり、解析のために入れたタグであっても、配信元の中身が変われば、会員登録や決済のフォームに入力された内容を外部に送ることが技術的には可能です。

なぜ「スキャンで十分」と感じてしまうのか

この取り違えが起きやすい理由は、3つあると考えています。

1つ目に、言葉が同じだから。外部スクリプトも、広い意味ではサイトが「依存している」ものです。「依存関係スキャン」という名前から、依存しているものはすべて調べたと受け取りやすくなります。

2つ目に、追加する人と管理する人が違いがちだから。ライブラリは開発者がコードに書き足しますが、解析や広告のタグは、マーケティング担当が管理画面から追加する運用も考えられます。開発側の一覧に載らない経路があると、棚卸しの対象からも漏れます。

3つ目に、問題が起きても自社のコードは変わらないから。上の2つの事例のように、サイト側に変更がないまま配信内容だけが変わります。変更履歴やコードレビューという、普段の点検の網にかかりません。

CSPを、防御の前に測定の手段として入れる

では、何から手をつければよいのか。筆者の判断は、CSPを「止める道具」としてではなく、まず「何が読み込まれているかを測る道具」として入れることです。

CSPは、サイトからブラウザへの指示で、そのページのコードに許される動作を制限させる仕組みです。主な用途は、どのリソース（特にJavaScript）を読み込んでよいかの制御で、XSSへの防御として使われます（MDN: Content Security Policy (CSP)）。

いきなり強制するモードで入れると、許可一覧に載っていないタグの読み込みが止まり、既存の機能が動かなくなる可能性があります。そこで使えるのが報告専用モードです。MDNによれば、Content-Security-Policy-Report-Only ヘッダーで配信したポリシーは強制されず、違反はポリシーで指定した報告先に送られます。寄稿記事も、このモードは何も強制せず、何もブロックせず、挙動も変えず、ポリシーが「ブロックしたであろうもの」を報告するだけだと説明しています。

この性質は、防御としては物足りなく見えます。しかし棚卸しの手段としては都合がよいと筆者は考えます。訪問者のブラウザが実際に読み込もうとしたものが、ブラウザ自身から報告されるからです。上で挙げた3つのずれ（取得のタイミング、取得する主体、応答の中身）を、訪問者の側から観測できます。

寄稿記事は、報告を集める仕組みが実際に異常を拾った例も挙げています。2026年9月、Report URIが収集したCSPの報告から、「ClickFix」系と呼ばれる手口を実行している侵害済みのECサイト群が見つかったといいます。偽の「人間であることの確認」画面に誘導し、PowerShell（Windowsのコマンド実行環境）のコマンドをクリップボードに置き、スケジュールされたタスクとして居座らせる流れで、攻撃者が管理するドメインの一部は、その時点で主要な評判判定サービスではまだ安全と評価されていたそうです。ただし、これは寄稿元のベンダー自身の検知事例で、自社サービスの紹介の文脈で書かれている点は割り引いて読む必要があります。サイト数や被害の規模は書かれていません。

確かなことと、まだ確かではないこと

確かなこと:

• CSPの報告専用モードでは、ポリシーは強制されず、違反は指定した報告先に送られる（MDN）
• Content-Security-Policy と Content-Security-Policy-Report-Only の両方があれば両方が有効になり、前者は強制、後者は報告のみになる（MDN）
• PCI SSC公式ブログによれば、PCI DSS v4.0 の新要件64件のうち51件は将来日付の要件で、2025年3月31日に発効する（PCI SSC公式ブログ）

寄稿記事の記述で、一次資料までは確認していないこと:

• 失効したCDNドメインの事例と、それを参照するサイトが「数千」あるという記述
• polyfill.io の件の詳細や、11万超という数値
• ClickFix 系の事例の規模

この記事で扱わないこと:

• 外部スクリプトの管理とPCI DSSの個別要件との対応関係。寄稿記事はこの点にも触れていますが、PCI SSCの一次資料で確認できなかったため、本記事では書いていません
• 特定の製品やサービスの推奨

報告専用モードで、最初の棚卸しをする手順

決済や会員登録のフォームがあるページを1つ選び、次の順で進めてください。

1. 開発者ツールで、いま読み込まれている外部スクリプトを書き出す。ブラウザの開発者ツールのネットワーク欄で、自社以外のドメインから読み込まれている .js を一覧にします。これが「自分の環境から見えた」一覧です
2. 依存関係の一覧と見比べる。1にあって、依存関係スキャンの対象（パッケージの一覧など）に載っていないものが、スキャンの外側にあるスクリプトです
3. 報告専用モードのCSPを入れる。自社と同じオリジンのスクリプトだけを許可するポリシーを、報告専用で配信します。報告先はMDNが推奨する report-to で指定します

Reporting-Endpoints: csp-endpoint="https://example.com/csp-reports"
Content-Security-Policy-Report-Only: script-src 'self'; report-to csp-endpoint

https://example.com/csp-reports は、報告を受け取るために自社で用意するURLに置き換えます。MDNは、古い指定方法の report-uri は非推奨としつつ、report-to が全ブラウザで使えるようになるまでは両方を宣言するよう勧めています。報告専用モードは <meta> タグでは配信できないため、レスポンスヘッダーで設定します。

1. 1〜2週間分の報告を、1の一覧と比べる。訪問者のブラウザから報告された読み込み先のうち、1の一覧に無かったものが、自分の環境からは見えていなかったスクリプトです

4で差が出なければ、少なくともその期間とそのページについては、見えている一覧と実際の読み込みが一致していたと言えます。差が出たなら、それが棚卸しの本当の出発点です。強制モードに切り替えるかどうかは、この一覧を見てから判断しても遅くありません。

外部から配信を受ける仕組みそのものはCDN入門：Webサイトを高速化する仕組みで、外部スクリプトが表示速度に与える影響はWebパフォーマンス最適化入門で扱っています。同じ外部スクリプトを、速度の観点と安全の観点の両方から見直すと、「このタグは本当に必要か」という判断の材料が揃います。

この記事で扱ったような判断を、自社の状況に照らして整理したい場合は、無料診断ツールで状況を言語化するところから始めることができます。