対策・学習19分で読める

外部スクリプト(サードパーティスクリプト)の安全な管理:棚卸し、SRI、CSP、フォーム送信先の確認

解析タグや広告タグなどの外部スクリプトはサイトと同じ権限で動きます。棚卸し、不要なタグの削除、SRI、CSPのscript-src・connect-src・form-actionの設定と点検の手順。

本文を読む
公開日
更新日
最終確認
目次

アクセス解析、広告、チャット、決済画面の部品、CDNから読み込むライブラリ。多くのサイトは、自分で書いていないスクリプトを毎回のページ表示で読み込んでいます。そのスクリプトは、サイト自身のコードと同じ権限で動きます。この記事では、外部スクリプトを把握し、できることを絞り、変化に気づくまでの手順を、OWASPとMDNの一次情報にもとづいて説明します(攻撃の方法は載せません)。

なぜ外部スクリプトが問題になるのか

OWASPの「Third Party JavaScript Management Cheat Sheet」は、第三者のJavaScriptを組み込むときのリスクを3つに分けています。

OWASPが挙げる3つのリスク
変更の管理を失う
提供元のコードが、開発・テストしたときと同じままである保証は通常ありません。提供元はいつでも新しい機能を入れられます
任意のコードが動く
第三者のコードは、組み込む側が事前に読むことがほとんどなく、利用者に与えられたのと同じ権限で実行されます。OWASPは、提供元のドメインが失効し、別の者に取り直されて悪意あるコードが置かれる例も挙げています
第三者への情報の開示
スクリプトを読み込むと、ブラウザは提供元のサーバーへ直接接続します。IPアドレスや、提供元が以前に設定したCookieなども提供元に届きます

タグマネージャーを使っている場合は、事情がもう一段複雑になります。OWASPは、タグマネージャー経由で返されるスクリプトは管理画面から即時に変えられ、次のページ表示からすぐに変わったコードが動くと説明しています。つまり、サイトのソースコードを見ても、実際に動くコードの全体は分かりません。

当サイトでも、外部スクリプトが関係した事例を扱っています。Polymarket の第三者スクリプトの事案と、APORITO オンラインストアのカード情報漏えいのおそれです。どちらも、利用者が見ているページで動くコードが問題になった型です。

自サイトのページ(表示内容・フォームの入力・Cookie)

↓ 同じページの中で動く

自サイトのスクリプト

自分でレビュー・配布できる

外部スクリプト

提供元が中身を変えられる。ページの内容を読める

外部へ送るフォーム

入力が別のオリジンへ届く

↓ 絞る手段

棚卸しと削除

SRI / 自サイトから配布 / CSP script-src・connect-src

CSP form-action

ページの中で動くものと、それぞれを絞る手段(一般的な対応づけ)

守り方:6つの手順

1

動いている外部スクリプトをすべて書き出す

最初にやるのは一覧づくりです。ページのHTMLに直接書かれたもの、タグマネージャーに登録したもの、ライブラリやプラグインが自動で読み込むものを含めます。

1つずつ、読み込み元のオリジン、誰のサービスか、何のために入れたか、どのページで動くか、問題が起きたときに誰がどう止めるかを書きます。スクリプトだけでなく、iframe や画像のように外部のサーバーへ接続するものも並べておくと、後の CSP 設定にそのまま使えます。

2

使っていないものを外し、重要なページでは絞る

一覧に「目的が分からない」「担当者がいない」ものがあれば、外す候補です。過去のキャンペーン用のタグや、乗り換え前の解析サービスが残っていることはよくあります。

ログイン、決済、パスワードやメールアドレスの変更、管理画面のように入力の価値が高いページでは、必要最小限にします。全ページ共通のテンプレートにタグを入れると、こうしたページにも入ってしまうので、ページの種類ごとに読み込むかどうかを分けてください。ページの内容に触れる必要がない部品は、OWASPが示すように、別ドメインの iframe(sandbox 属性つき)に入れてページから切り離す方法もあります。

3

タグマネージャーの公開権限を絞る

OWASPは、データレイヤー(タグに渡す値をまとめた入れ物)は隔離の仕組みではなく、タグマネージャーのコンテナはカスタムのJavaScriptやHTMLタグを実行できると注意しています。そのうえで、公開の権限を限定し、変更をアプリのコードと同じようにレビューするよう勧めています。

具体的には、公開できる人を数人に限る、管理画面のアカウントに2段階認証を設定する、使わないならカスタムHTMLタグを無効にする、公開前に別の人が確認する、の4つから始めます。

4

中身が固定のファイルには SRI を付けるか、自サイトから配る

SRI(サブリソース完全性)は、<script> などに integrity 属性でファイルのハッシュを書いておき、受け取ったファイルが一致しなければブラウザが読み込みを拒否する仕組みです。MDNによれば、使えるハッシュは sha256・sha384・sha512 で、別オリジンから読み込む場合は提供元が CORS を許可している必要があり、crossorigin 属性も付けます。

SRIが使えるのは、版番号つきのライブラリのように中身が変わらないファイルだけです。解析タグのように提供元が随時更新するものに付けると、更新のたびに読み込めなくなります。その場合は、確認した版を自サイトから配る(OWASPの言う in-house mirroring)か、重要なページでは読み込まないことを選びます。ライブラリの既知の脆弱性は、依存パッケージ脆弱性スキャナで lockfile から確認できます。

5

CSP で読み込み元と送信先を絞る

CSP(Content-Security-Policy)では、手順1の一覧をもとに許可するオリジンを書きます。script-src はスクリプトの読み込み元、connect-src は fetch・XMLHttpRequest・WebSocket・EventSource・sendBeacon などの送信先を制限します(MDN)。

フォームの送信先を制限する form-action は、default-src で代用されません。MDNは、設定しなければ何でも許可されると説明しています。自サイトにしか送らないなら form-action 'self' を明示します。

いきなり適用すると正規の機能が止まることがあるので、まず Content-Security-Policy-Report-Only で違反の報告だけを集めます。MDNによれば、報告を受け取るには report-to の指定が必要で、このヘッダーは <meta> 要素では使えません(非推奨の report-uri でも報告を送れます)。組み立ては CSPビルダー で試せます。ヘッダー全体の考え方はセキュリティヘッダの選び方にまとめています。

6

変化に気づける状態にし、止める手順を決めておく

外部スクリプトは、こちらが何もしなくても変わります。月に1回など決まった間隔で一覧と実際の状態を比べ、CSP の違反報告に知らない送信先が出たら調べます。提供元のセキュリティ情報の通知を受け取れるようにしておきます。

問題が起きたときに、どのタグを、誰が、どの画面から止めるかを文書にしておきます。カード決済のページを持つ事業者は、PCI DSS v4.0.1 の決済ページの安全性に関する要件 6.4.3 と 11.6.1 が2025年3月31日から有効になっている点も確認してください(PCI SSC)。カード情報の処理をすべて外部の準拠事業者に任せている加盟店向けの SAQ A では、この2つの要件が外れ、代わりに「自社サイトが、電子商取引のシステムに影響しうるスクリプトによる攻撃を受けにくいこと」を確かめる適格条件が加わりました(基準そのものの要件は変わりません)。

4つの対策で、防げることと防げないこと

対策防げること防げないこと向くもの
外すそのスクリプトに関するすべてのリスク―目的が分からないもの・使っていないもの
SRI配信途中や提供元での中身の差し替え改ざんされていないスクリプトが正規の機能として送る情報。提供元の更新で読み込めなくなる版番号つきの固定ファイル
自サイトから配る提供元側での差し替え自分で更新しないと古い版が残る確認したうえで使い続けるライブラリ
CSP許可していないオリジンからの読み込み・許可していない送信先への通信やフォーム送信許可したオリジン自体が侵害された場合。許可した送信先に送られる情報すべてのページ(段階的に導入)

広がりやすい状態

  • 全ページ共通のテンプレートにタグを入れている
  • タグマネージャーの公開権限を多くの人が持っている
  • CSP がない、または form-action を書いていない
  • 外部スクリプトの一覧がなく、止め方が決まっていない

絞り込めている状態

  • ページの種類ごとに読み込むタグを分けている
  • 公開できる人が限られ、変更は別の人が確認する
  • CSP で読み込み元・送信先・フォーム送信先を固定している
  • 一覧があり、定期的に実際の状態と比べている

サイト透明性チェッカーで結果を確かめる

一覧を作ったら、実際の状態と比べます。サイト透明性チェッカーに自分が管理するサイトのトップページのURLを入れると、取得したHTMLから次の項目を拾います。

ツールの結果の見方
外部スクリプト/リソースの送信元
script・iframe・img・link(stylesheet・preload など)で参照している別オリジンの一覧。手順1の一覧にないものがあれば、何のためのものか調べる
解析・広告タグ(トラッキング)
よく使われる解析・広告・監視サービスの読み込みを名前で表示。名前は参照先の分類で、安全かどうかの判定ではない
外部スクリプト(知名度による安全判定なし)
別オリジンから読み込むスクリプト。知名度で安全と判定はしない
外部へ送信するフォーム
form の action や button の formaction が別オリジンを指しているもの。意図したものでなければ最優先で確認し、CSP の form-action で固定する
取得応答のSet-Cookie
取得した応答に Set-Cookie があるか。JavaScript で設定されるものは確認しない

このツールには限界があります。トップページ(言語別トップページと index.html を含む)だけを取得し、スクリプトを実行せず、埋め込み先のファイルを追加取得しません。タグマネージャーが後から読み込むスクリプトや、ボタンを押したときだけ起きる通信は見えません。そのため、次の確認も合わせて行います。

  1. 確認したいページ(ログインや決済のページを含む)を開き、ブラウザの開発者ツールを開く
  2. Network タブで記録し、仮のデータで実際に入力・操作する
  3. 一覧にない外部ドメインへの通信がないかを見る
  4. CSP を設定した後は、セキュリティヘッダ診断でヘッダーが実際に返っているかを確かめる

日本でサイトを運営する場合:外部送信規律

総務省によれば、2022年6月の電気通信事業法の改正で、タグや情報収集モジュールで利用者の情報を外部に送信させる場合に利用者が確認できるようにする規律が設けられました(施行は2023年6月16日)。対象は電気通信事業を営む者で、総務省は、メッセージ媒介サービス、SNS、検索サービス、ニュースサイトやまとめサイトなどの情報提供サービスを主な対象に挙げる一方、自社商品のオンライン販売や企業のホームページ、個人ブログは電気通信事業に該当せず対象にならないとしています。

対象になる場合は、送信される情報の内容、その情報を取り扱う者の氏名または名称、利用目的を、通知するか利用者が容易に知り得る状態に置くなどの対応が必要です。手順1の一覧は、この公表内容を作るときにも使えます。自社が対象かどうかは、総務省の説明とフローチャートで確認してください。

当サイトの視点:知名度ではなく、そのページで何を読めるかで判断する

外部スクリプトの点検では、「有名なサービスだから大丈夫」という判断になりがちです。しかし、OWASPが最大のリスクとして挙げるのは、提供元のサーバーが侵害されることです。有名なサービスほど多くのサイトに入っているので、侵害されたときの影響も広がります。

当サイトのサイト透明性チェッカーが、有名な提供元でも安全と表示しないのはこのためです。判断の基準は、そのスクリプトがどのページで動き、何を読めて、問題が起きたら何分で止められるか、の3つです。

出典(一次情報)

  • OWASP「Third Party JavaScript Management Cheat Sheet」— cheatsheetseries.owasp.org(3つのリスク、タグマネージャー、SRI、iframe による分離、in-house mirroring)
  • MDN「Subresource Integrity」— developer.mozilla.org(integrity 属性、使えるハッシュ、CORS と crossorigin 属性)
  • MDN「Content Security Policy (CSP)」— developer.mozilla.org(script-src、report-only での試験)
  • MDN「CSP: form-action」— developer.mozilla.org(default-src による代替なし)
  • MDN「CSP: connect-src」— developer.mozilla.org(対象の API)
  • MDN「Content-Security-Policy-Report-Only」— developer.mozilla.org(report-to が必要、meta 要素では使えない)
  • PCI SSC「Important Updates Announced for Merchants Validating to Self-Assessment Questionnaire A」(2025年1月30日)— blog.pcisecuritystandards.org(要件 6.4.3・11.6.1 は2025年3月31日から有効)
  • 総務省「外部送信規律」— soumu.go.jp(趣旨・対象・公表事項)

次に読む

よくある質問

Q大手の解析サービスのスクリプトなら安全ですか?
A

有名であることは、改ざんされないことの保証になりません。OWASPの第三者JavaScript管理のチートシートは、最大のリスクを『第三者のJavaScriptサーバーが侵害され、元のタグに悪意あるコードが注入されること』としています。また、ページに読み込んだ外部スクリプトは、利用者と同じ権限でページの内容に触れられます。提供元の知名度ではなく、そのページで何を読めるか、止める手順があるかで判断してください。

QSRI(integrity属性)を付ければ外部スクリプトの対策は十分ですか?
A

十分ではありません。SRIは、受け取ったファイルが事前に計算したハッシュと一致しない場合にブラウザが読み込みを拒否する仕組みで、中身が固定のファイルにしか使えません。提供元が正規にファイルを更新すると読み込めなくなります(OWASPも、提供元の更新で動かなくなることがあると注意しています)。また、改ざんされていないスクリプトが正規の機能として何を送るかは制限しません。CSPと、不要なスクリプトを外すことを組み合わせます。

QCSPで default-src を設定していれば、フォームの送信先も制限されますか?
A

されません。MDNは form-action ディレクティブについて、default-src による代替(フォールバック)は『ない』とし、『設定しなければ何でも許可される』と説明しています。フォームの送信先を絞りたいときは form-action を個別に書いてください。一方、fetch や XMLHttpRequest、WebSocket、sendBeacon などの送信先を制限する connect-src は、未設定なら default-src が使われます。

Qサイト透明性チェッカーで何も検出されなければ、外部送信はないと言えますか?
A

言えません。このツールは取得したトップページ等のHTMLを静的に点検するもので、スクリプトを実行せず、埋め込み先のファイルも追加取得しません。タグマネージャーが後から読み込むスクリプトや、操作したときだけ起きる通信は見えません。『静的には見つからなかった』という手がかりとして使い、最終確認はブラウザの開発者ツールのNetworkタブで行ってください。