外部スクリプト配信元を限定するには？配信ホスト数のリスク・集約方法・診断基準

外部スクリプト配信元を限定するとは

外部スクリプト配信元を限定するとは、Webページが外部JavaScriptを読み込むホスト（ドメイン）の種類を、必要最小限に絞ることです。

外部JavaScriptを読み込むとき、そのファイルを配信するホスト1つ1つが、自治体サイトのページで任意のコードを実行できる「信頼の境界」になります。同じ件数のスクリプトでも、1つのCDNから配信されている場合と、7つの異なる事業者から配信されている場合とでは、侵害・ドメイン失効・提供終了などのリスクを負う相手の数が違います。

セキュリティAIチェッカーのこの項目は、トップページで読み込まれている外部JavaScriptの配信元ホスト名の種類数を数え、信頼する相手が増えすぎていないかを確認します。件数は「外部JavaScript依存数」で、改ざん検知は「外部JavaScriptのSRI」で別に評価します。

ホスト名とオリジンの数え方

この項目ではホスト名（例: www.googletagmanager.com）を単位に数えます。同一事業者でも www.google-analytics.com と www.googletagmanager.com は別ホストとして数えます。ポートやスキームは区別しません。

外部スクリプトの配信元の数がなぜリスクになるのか

• 侵害されうる相手の数：配信元の事業者のサーバー、CDNアカウント、ビルド環境のどれか1つが侵害されれば、悪性コードが配信されます。
• ドメインの失効・譲渡：サービス終了後にドメインが失効し、第三者に再取得されると、そのドメインから任意のスクリプトを配信できます。2024年のpolyfill.ioの事例では、ドメインと配信サービスが第三者に売却された後に配信スクリプトが改変され、Sansecの報告では、このスクリプトを埋め込んでいた10万を超えるサイトが影響を受けました。
• CSPの許可リストの肥大化：配信元が多いほど、Content Security Policyの script-src に列挙するオリジンが増え、許可リストが緩くなりがちです。特に、任意の利用者がファイルを置けるCDN（汎用のnpm配信CDNなど）をドメイン単位で許可すると、そこに置かれた別のファイルも実行を許すことになります。CSPのワイルドカードは「CSPの過剰なワイルドカード」で確認します。
• データの送信先の増加：OWASPのチートシートが指摘するとおり、外部スクリプトを読み込むたびにブラウザはその配信元へ直接接続し、リファラーなどの情報を送ります。

外部スクリプト配信元を限定の診断基準（セキュリティAIチェッカー）

取得対象

• 入力URLのリダイレクト後の最終URLのHTML本文（最大2MB）を対象にします。
• 「外部JavaScript依存数」と同じ外部JavaScriptの集合（<script ... src="..."> のうち、解決後のオリジンがページと異なるもの）から、ホスト名を重複なく集めます。HTMLに直接書かれていないスクリプト（タグマネージャー経由など）は含まれません。

判定条件

• この項目に×（fail）と対象外（na）はありません。外部スクリプトがないサイトは0ホストとして○になります。
• 4ホストという閾値は、アクセス解析、タグマネージャー、アクセシビリティ支援、地図程度の一般的な構成を許容するための運用上の目安であり、標準規格で定められた数値ではありません。
• 根拠欄には配信元ホスト数を表示します。重大度はmedium、重みは2です。

自治体サイトでの判定例

検出の限界

• 実行時に動的に読み込まれるスクリプトの配信元は数えないため、実際の配信元はこれより多いことがあります。タグマネージャーを使っているサイトでは、タグマネージャーの管理画面で配信先の一覧を確認してください。
• 同じ事業者の複数のホストは別々に数え、異なる事業者が同じCDNを共有している場合は1つとして数えます。数は「信頼する相手の数」の近似値です。
• 配信元の信頼性そのもの（契約の有無、ドメインの管理状況）は外部から判定できません。

配信元を評価する観点

台帳には、ホスト名ごとにこれらの観点を記録し、利用終了時にHTMLとタグマネージャーの両方からタグを削除したことを確認する欄を設けると、失効ドメインの乗っ取りを防ぎやすくなります。

外部スクリプトの配信元が多いとどんなリスクがあるか

• 一点突破による全利用者への影響：配信元のどれか1つが侵害されれば、トップページを開いたすべての利用者が影響を受けます。英国ICOは、Ticketmasterの決済ページに置かれた第三者のチャットボットのスクリプトが悪用された2018年の事案で、2020年に125万ポンドの制裁金を科しています。
• 失効ドメインの乗っ取り：過去に使っていたサービスのドメインが失効し、スクリプトタグだけがHTMLに残っている場合、第三者がドメインを取得すると任意のコードを配信できます。
• 管理責任の所在不明：配信元が多いと、どの課の誰が導入し、どの契約で、何のデータが送られているかが分からなくなり、インシデント時の切り分けが遅れます。
• 個人情報・閲覧情報の第三者提供：配信元ごとに利用者の閲覧情報が送信されるため、自治体のプライバシーポリシーや外部送信規律に関する説明との整合が必要になります。

外部スクリプト配信元を限定する方法（一覧化・集約・CSP）

1. 配信元の一覧化

curl -s https://www.city.example.lg.jp/ \
  | grep -o -i -E '<script[^>]*src="(https?:)?//[^"/]+' \
  | sed -E 's#.*//##' | sort | uniq -c | sort -rn

ブラウザの開発者ツール「ネットワーク」タブで種類「JS」に絞り、「ドメイン」列を表示すると、タグマネージャー経由で読み込まれる配信元も含めて確認できます。

2. 集約・削減の方針

3. CSPで許可する配信元を明示

配信元の台帳ができたら、そのままCSPの許可リストにします。ホスト単位で必要最小限を列挙し、汎用CDNはドメイン全体ではなくパスまで限定することも検討します（CSPのソース式はパス指定に対応していますが、リダイレクト後はパス部分が照合されない点に注意）。

Apache（.htaccess）

<IfModule mod_headers.c>
  Header always set Content-Security-Policy-Report-Only "script-src 'self' https://www.googletagmanager.com https://translate.example-vendor.jp; object-src 'none'; base-uri 'self'; report-uri /csp-report"
</IfModule>

nginx

add_header Content-Security-Policy-Report-Only "script-src 'self' https://www.googletagmanager.com https://translate.example-vendor.jp; object-src 'none'; base-uri 'self'; report-uri /csp-report" always;

IIS（web.config）

<httpProtocol>
  <customHeaders>
    <add name="Content-Security-Policy-Report-Only"
         value="script-src 'self' https://www.googletagmanager.com https://translate.example-vendor.jp; object-src 'none'; base-uri 'self'" />
  </customHeaders>
</httpProtocol>

Next.js（Vercel）

// next.config.js
module.exports = {
  async headers() {
    return [{
      source: "/(.*)",
      headers: [{
        key: "Content-Security-Policy-Report-Only",
        value: "script-src 'self' https://www.googletagmanager.com; object-src 'none'; base-uri 'self'",
      }],
    }];
  },
};

違反の報告先の設定は「CSP違反の報告先」で確認します。

4. 段階的な削減手順

1. 一覧化した配信元ごとに、担当課へ「現在も必要か」「代替手段はあるか」を照会する
2. 不要と確認できたタグを、HTMLテンプレートとタグマネージャーの両方から削除する
3. 版固定できるライブラリを自己ホストへ移し、汎用CDNへの依存をなくす
4. 残った配信元をCSPのReport-Onlyに列挙し、1〜2週間ほど違反の有無を観察する
5. 違反がなければCSPを強制に切り替え、以後は台帳の更新とCSPの更新を同じ手続きで行う

5. 運用ルール

• 外部スクリプトの追加は、目的・送信データ・契約・担当者を記載した申請と承認を経て行う
• 年1回以上、台帳と実際の読み込みを突き合わせ、不要なものを削除する
• 委託先（CMS保守事業者・制作会社）にも同じルールを契約で求める
• 新規導入の審査では、既存の配信元で代替できないかを最初に確認する
• サービスの利用終了時は、契約終了の手続きと同時にタグの削除を完了させ、ドメイン失効後にタグだけが残る状態を作らない

サイトを壊さないための注意点

• CSPはまずReport-Onlyで運用し、違反レポートやブラウザのコンソールで、許可漏れの配信元がないことを確認してから強制に切り替えてください。インラインスクリプトが多いCMSでは、script-src の強制で機能が停止することがあります。
• タグマネージャーで配信しているタグは、タグマネージャー側の設定も整理しないと、HTMLから消しても読み込まれ続けます。
• 翻訳・読み上げなどアクセシビリティ支援の削除は、利用者への影響が大きいため、代替手段を用意してから行ってください。

整理後はセキュリティAIチェッカーで再診断し、根拠欄の配信元ホスト数が4以下になったことを確認します。

よくある質問（FAQ）

参考資料

• OWASP Third Party JavaScript Management Cheat Sheet
• OWASP ASVS 5.0.0 V3 Web Frontend Security（V3.6.1）
• Sansec「Polyfill supply chain attack」
• ITPro「Ticketmaster fined £1.25m for…」

「外部スクリプト配信元を限定」と関連する診断項目

• 外部JavaScript依存数medium
• 外部JavaScriptのSRImedium
• CSPの過剰なワイルドカードhigh
• CSP違反の報告先low
• Mixed Contentがないhigh
• WebSocketをWSSで暗号化high
• 廃止されたクライアント技術を使用していないhigh
• postMessageの送受信元を限定high