そのタグ、誰が管理していますか？ 外部スクリプトとWebスキミングから決済ページを守る

ECサイトや企業サイトには、自社で作ったHTMLやプログラムのほかに、外部の会社が提供するスクリプト（JavaScriptで書かれた小さなプログラム）が数多く読み込まれています。アクセス解析、広告の効果測定、チャット窓口、レビューの表示、ヒートマップなど、いわゆる「タグ」と呼ばれるものです。Googleタグマネージャーを使えば、HTMLを書き換えずに管理画面からタグを追加できるため、マーケティング担当者や広告代理店が自分でタグを設置することも珍しくありません。

便利になった一方で、「いまサイトに何のタグが載っていて、誰が追加したのか」を正確に答えられる会社は多くありません。2024年6月には、古いブラウザ向けの補助機能として多くのサイトで読み込まれていた外部スクリプトの配信元「polyfill.io」で、悪意のあるコードが配信されていたことが報告されました。セキュリティ企業Sansecは、影響を受けたサイトが10万を超えると報告しています。サイトを運営する側が何も変更していなくても、読み込んでいる外部スクリプトの中身が変われば、訪問者のブラウザでは別のプログラムが動くことになります。

決済ページで同じことが起きると、被害はより深刻になります。入力されたクレジットカード番号を、そのまま攻撃者に送るスクリプトが仕込まれる「Webスキミング」と呼ばれる手口です。日本クレジット協会は、カード情報を自社で保持しない「非保持化」を実現したEC加盟店でも、Webサイトの脆弱性などを原因としたカード情報の窃取が発生していると説明しています。

これまでの連載では、自動化された攻撃の構造や、WordPressを放置する危険を取り上げてきました。今回は、サイトの「外側から持ち込まれるコード」に目を向けます。私はフリーランスのWebディレクター兼エンジニアとして、サイトの設計から実装、公開後の運用まで関わる中で、タグの追加や整理を相談されることがあります。

この記事では、中小企業のEC担当者・Web担当者の方と、サイトを納品するWeb制作者の方に向けて、外部タグの落とし穴と、棚卸し・権限管理・CSP（コンテンツセキュリティポリシー）という三つの備えを順に整理します。専門的な設定に入る前に、社内で今日から確認できることを中心にまとめています。CSPのように制作者の協力が必要な対策についても、発注する側が判断できるよう、考え方と注意点を中心に説明します。

Webスキミングとは：カード番号を「入力した瞬間」に盗む手口

正規のサイトの上で、情報が抜き取られる

Webスキミングは、ECサイトの決済画面や会員登録画面に不正なスクリプトを紛れ込ませ、訪問者が入力した情報を外部に送信させる手口です。IPA（情報処理推進機構）の「情報セキュリティ10大脅威」の解説資料では、正規のショッピングサイトの決済画面を改ざんし、偽の決済画面でカード情報を入力させる手口について、正規サイト上に偽の画面が作られているため、利用者がドメインに気を付けていても見抜くことは極めて難しいと説明されています。

お店にたとえると、レジの横に、店員も気付かない小さなカメラを取り付けられるようなものです。お客様はいつものお店で、いつものように支払っているだけなので、異常に気付く手がかりがほとんどありません。サイトの見た目が変わらないまま情報だけが流れていくため、カード会社からの連絡で初めて発覚することもあります。

「カード情報を持っていないから大丈夫」とは言い切れない

ここで押さえておきたいのは、カード情報をサーバーに保存していないサイトでも、この手口の対象になり得るという点です。スキミングのスクリプトは、サーバーに保存されたデータではなく、訪問者のブラウザ上で入力された値を読み取ります。そのため、保存しない設計にしていても、入力画面に不正なスクリプトが入り込めば被害が起きる可能性があります。

こうした状況を受けて、割賦販売法の実務上の指針とされる「クレジットカード・セキュリティガイドライン」は2025年3月に6.0版へ改訂され、EC加盟店に対して、システムやWebサイトの脆弱性対策の実施が加わりました（経済産業省の発表）。管理画面のアクセス制限や二段階認証、Webアプリケーションの脆弱性対策などが具体的な項目として示されています。

国際基準でも「決済ページのスクリプト管理」が求められている

カード業界の国際的なセキュリティ基準であるPCI DSSでも、v4.x の要件6.4.3と11.6.1として、決済ページで読み込まれるスクリプトを許可・確認・一覧化し、改ざんを検知する仕組みが求められています。基準を策定するPCI SSCは、外部スクリプトへの依存が増えたことでスキミング攻撃が増加しているとして、2025年3月に解説資料を公開しました。中小規模のECサイトがこの基準を直接求められるかどうかは契約形態によって異なりますが、「決済ページに載るスクリプトは一つずつ管理する」という考え方は、規模を問わず参考になります。

提供元が乗っ取られたら：外部タグは「他社のコードを自社ページで動かす」こと

タグの中身は、提供元がいつでも変えられる

外部タグを設置するとき、多くの場合は提供元から渡された数行のコードをHTMLやGoogleタグマネージャーに貼り付けます。このコードは、提供元のサーバーにある本体のスクリプトを読み込むための「呼び出し口」にすぎません。実際にブラウザで動くプログラムの中身は、提供元のサーバー側に置かれており、提供元はサイト運営者に知らせることなく内容を更新できます。

これは、機能の改善や不具合の修正をすぐに反映できるという利点でもあります。一方で、提供元のサーバーやアカウントが乗っ取られたり、サービス自体が別の運営者に渡ったりすると、自社のページで動くプログラムが知らないうちに入れ替わることを意味します。外部タグを載せることは、合鍵を業者に渡して、店の中で自由に作業してもらうことに近いといえます。

polyfill.io の事例から分かること

冒頭で触れた polyfill.io の件では、フランスの政府機関CERT-FRのまとめによると、2024年2月にライブラリとドメインが別の企業に買収され、その後、利用者を賭博サイトなどに転送するコードへの変更が確認されました。Cloudflareは、自社のサービスを経由しているサイトについて、polyfill.io への参照を自社の安全な複製へ自動で置き換える措置を発表しています。その後、ドメインの登録事業者がドメインを停止したことで、配信は止まりました。

この件で重要なのは、影響を受けたサイトの多くが、何年も前に設置したスクリプトをそのまま使い続けていただけだという点です。サイト側に弱点があったわけではなく、「信頼して読み込んでいた先」が変わったことで被害の入り口になりました。CERT-FRは対策として、polyfill.io の利用をやめることに加え、外部コンテンツの完全性の確認と、読み込み先を許可リストで制限する仕組み（後述するCSP）の導入を推奨しています。

タグが増えるほど、見えない入り口も増える

タグは一つ追加するたびに、確認すべき提供元が一社増えることになります。アクセス解析、広告、チャット、レビューと積み重ねていくと、いつの間にか十数社のコードが同じページで動いている状態になることも珍しくありません。どの会社のセキュリティ体制も、自社からは直接確認できません。だからこそ、「必要なタグだけを載せる」「載せる場所を限定する」という管理の考え方が大切になります。

使っていないタグの棚卸し：まず「何が載っているか」を一覧にする

一覧表を作るところから始める

対策の第一歩は、サイトに載っているタグを一覧にすることです。PCI SSCの解説資料でも、決済ページのスクリプトの一覧と、それぞれが必要な理由を記録することが求められており、規模の小さい環境であれば表計算ソフトで足りる場合があると書かれています。専用のツールがなくても始められる作業です。

一覧には、次のような項目を並べておくと、後の判断がしやすくなります。

調べ方としては、Googleタグマネージャーの管理画面でタグの一覧を確認するほか、ブラウザの開発者ツールで、ページを開いたときにどのドメインからスクリプトが読み込まれているかを見る方法があります。テーマやプラグインにタグが直接書き込まれている場合もあるため、制作会社に確認を依頼すると漏れを減らせます。一度作った一覧は、タグを追加・削除するたびに更新し、半年に一度など時期を決めて見直すと、古い情報のまま放置されにくくなります。

悪い例 vs 改善例

悪い例: 数年前のキャンペーンで使った広告タグや、すでに解約したチャットサービスのタグが、誰も把握しないまま全ページに残っている。決済ページにも、アクセス解析以外のタグがすべて同じように読み込まれている。

改善例: 一覧表で用途と担当者が確認できないタグは、関係者に確認したうえで停止する。決済ページや会員情報の入力ページは、決済に必要なものと最低限の計測タグだけに絞り、それ以外のタグは読み込まない設定にする。

現場でつまずきやすい点

棚卸しで多いのが、「外すと何かが止まるかもしれないので触れない」という判断です。担当者が退職していたり、代理店との契約が終わっていたりすると、タグの目的を知る人がいないこともあります。この場合は、いきなり削除するのではなく、Googleタグマネージャー上で一時停止して影響を確認し、問題がなければ削除する、という段階を踏むと安全に進められます。担当者の交代に備えたアカウントの引き継ぎについては、担当者退職後の契約とログインの控えも参考にしてください。

タグを追加できる人を絞る：Googleタグマネージャーの権限と公開の流れ

権限は「読み取り・編集・承認・公開」の段階で分けられる

Googleタグマネージャーは、HTMLを触らずにタグを追加できる便利な仕組みですが、裏を返せば、公開の権限を持つ人なら誰でも、全ページで動くスクリプトを追加できるということです。サイトの中身を書き換える権限と同じくらいの重さがあると考えて、管理する必要があります。

Googleのヘルプによると、コンテナ単位の権限は「読み取り」「編集」「承認」「公開」に分かれています。編集権限ではワークスペースの作成や編集はできますが、バージョンの作成や公開はできません。なお「承認」の権限と承認のワークフローは、有料版のGoogleタグマネージャー360でのみ利用できると説明されています。

悪い例 vs 改善例

悪い例: 広告代理店、前任の制作会社、退職した社員など、過去に関わった全員が「公開」権限を持ったまま残っている。誰がいつ何を公開したのか、社内で説明できない。

改善例: 公開権限は社内の責任者と、保守を任せている制作者など少人数に限る。外部の代理店には編集権限を付与し、設定が終わったら連絡をもらって、社内で内容を確認してから公開する。契約が終わった相手のアカウントは、その時点で削除する。

管理者を二人以上、社内に置く

同じヘルプでは、管理者が一人しかいない場合、その人が対応できなくなるとアクセスを失うおそれがあるため、管理者を少なくとも二人用意することと、アカウントの管理は外部の代理店ではなく組織内の担当者が行うことが勧められています。制作会社や代理店のアカウントが管理者になっている状態は、引き継ぎのたびに混乱を生みやすくなります。

公開のたびに「何を、なぜ」を残す

公開するときには、バージョン名と説明を入力できます。「◯◯キャンペーンの計測タグを追加（担当：営業部）」のように目的と担当を書き残しておくと、後の棚卸しで判断がしやすくなります。あわせて、タグマネージャーにログインするGoogleアカウントには二段階認証を設定しておきます。アカウント自体が乗っ取られれば、権限をどれだけ整理していても意味が薄れてしまうためです。

現場でつまずきやすい点

よくあるのが、制作会社や代理店の担当者個人のGoogleアカウントに権限を付けていて、担当者の異動や退職で誰も把握していないアカウントが残るケースです。権限の一覧は、ユーザー管理の画面からいつでも確認できます。棚卸しのときに、タグの一覧とあわせて「誰が公開できるか」も見直す習慣をつけておくと、管理の抜けを防ぎやすくなります。

CSP（コンテンツセキュリティポリシー）の考え方：読み込んでよい提供元をブラウザに伝える

「この提供元のスクリプトだけ動かしてよい」という許可リスト

CSPは、Webサーバーからブラウザに対して「このページでは、ここに書いた提供元のスクリプトだけを実行してよい」と伝える仕組みです。HTTPレスポンスヘッダーで指定します。Chromeの開発者向け資料では、攻撃者がスクリプトを挿入できたとしても、許可リストに一致しなければ実行されないと説明されています。受付に「入館を許可する会社の一覧」を渡しておくようなものです。

たとえば、次の指定では、自社のドメインと、指定した一つの提供元からのスクリプトだけが実行されます。

Content-Security-Policy: script-src 'self' https://tag.example-analytics.com

いきなり適用せず「報告のみ」で様子を見る

外部タグが多いサイトに厳しいCSPをいきなり適用すると、必要なタグまで止まり、計測やチャットが動かなくなることがあります。そこで、まずは Content-Security-Policy-Report-Only ヘッダーを使う方法があります。MDNの解説によると、このヘッダーはポリシーを強制せずに違反を報告するもので、報告を受け取るには report-to の指定が必要です。

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

報告を一定期間集めると、「許可リストにないのに読み込まれているスクリプト」が見えてきます。これは、棚卸しで見落としていたタグを見つける手がかりにもなります。

CSPの限界と、現場でつまずきやすい点

CSPは強力ですが、万能ではありません。許可した提供元そのものが乗っ取られた場合、polyfill.io の件のように、許可リストを通過したスクリプトが不正な動きをする可能性があります。読み込むファイルの指紋（ハッシュ値）を指定するSRI（サブリソース完全性）という仕組みもありますが、PCI SSCの解説資料では、頻繁に中身が変わる外部スクリプトには実用的でないとされています。

また、Googleタグマネージャー経由で多くのタグを読み込んでいると、許可すべき提供元が増え、結果として許可リストが広くなりすぎることがあります。現実的には、決済ページや会員情報の入力ページから先に、載せるタグを絞ったうえでCSPを設定し、他のページは段階的に広げていく進め方が取り組みやすいと考えています。

まとめ：タグは「便利な部品」であり「他社に開けた入り口」でもある

外部タグは、アクセス解析や広告、チャットなど、サイトの成果を高めるために欠かせない部品です。ただし、その中身は提供元のサーバーにあり、自社では直接管理できません。提供元が乗っ取られたり、運営者が変わったりすれば、自社が何も変更していなくても、訪問者のブラウザでは別のプログラムが動く可能性があります。決済ページでそれが起きれば、カード情報を保存していないサイトでも、入力された情報が盗まれるおそれがあります。

この記事では、三つの備えを紹介しました。一つ目は、載っているタグを一覧にして、用途や担当者が分からないものを整理する棚卸しです。二つ目は、Googleタグマネージャーで公開できる人を少人数に絞り、契約が終わった相手の権限を外す権限管理です。三つ目は、CSPで「読み込んでよい提供元」をブラウザに伝え、まずは報告のみのモードで様子を見ながら、決済ページから段階的に適用していく方法です。どれか一つで完結するものではなく、組み合わせることで、見えない入り口を少しずつ減らしていけます。

発注する企業の方にとっては、タグの追加は「マーケティングの作業」と捉えられがちですが、実際にはサイトの中身を書き換える行為に近いものです。制作者の方にとっても、納品後に誰がどのタグを追加しているかを把握しにくいことは、保守を引き受けるうえでのリスクになります。公開後の運用ルールに、タグの追加と削除の手順を含めておくことをおすすめします。見積もりや保守契約の段階で「タグの管理は誰が担当するか」を決めておくだけでも、後の混乱を避けやすくなります。

まずは、次の3つを確認するところから始めてみてください。

1. Googleタグマネージャーで「公開」権限を持っている人の中に、すでに関係が終わった人や会社が含まれていないか
2. 決済ページや会員情報の入力ページで、決済や計測に必要のないタグが読み込まれていないか
3. 用途と社内の担当者を説明できないタグが、サイトに残っていないか

一つでも答えに迷う項目があれば、そこから整理を始めるのがよいと思います。制作者の方であれば、次の保守の打ち合わせで、この3つをクライアントと一緒に確認してみてください。

「自社サイトに何のタグが載っているか分からない」「決済ページのスクリプトを整理し、CSPの導入も検討したい」とお考えの企業・店舗の方は、現状の洗い出しからご相談を承っています。相談・お問い合わせからお気軽にご連絡ください。