クレジットカード番号を自社サーバーへ保存していなくても、ECサイトが安全とは限りません。攻撃者がチェックアウト画面へ不正なJavaScriptを一行加えれば、正規の決済は成功したまま、入力中のカード情報だけを別の送信先へ複製できます。売上や画面に異常が出にくい点が、eスキミングの厄介さです。
PCI DSS 4.0.1の決済ページ対策で問われるのは、「カード情報を持っているか」だけではありません。消費者のブラウザに何を実行させ、誰が許可し、何が変わったら、誰が止めるかを説明できるかです。
本記事は2026年9月1日時点のPCI Security Standards Council（PCI SSC）公式資料を基に、要件6.4.3と11.6.1を日本のEC運営へ落としました。契約するアクワイアラ、カードブランド、QSA、採用する自己問診票、決済代行サービスの実装によって対象範囲は変わります。本文だけで自己判断せず、最終的な適格性は提出先と確認してください。
最初に決済方式をブラウザで確定する
名称ではなく、購入者のブラウザへ誰がどの要素を届けるかを確認します。
管理画面の設定名やベンダーの営業資料だけでは、決済ページの構成を判定できません。テスト注文を行い、ブラウザの開発者ツールで文書、iframe、JavaScript、通信先、HTTPヘッダーを記録します。PCとスマートフォン、通常注文と会員注文、3Dセキュア認証、クーポン、住所自動入力、タグ管理の有無も分けます。
決済代行会社の画面へHTTPリダイレクトする方式では、カード入力画面そのものは代行会社のドメインで提供されます。埋め込みiframeでは自社の商品・注文画面の中に、代行会社から直接届く決済要素が入ります。Direct PostやJavaScriptフォームでは、自社ページから提供された要素がカード情報の収集や送信に関わる場合があります。
PCI SSCのFAQは、SAQ Aでiframeを使う場合、カード情報の取得に関わるすべてのフィールドとWeb要素が、PCI DSS準拠の第三者サービス事業者から直接提供されるiframe内にあることを示しています。自社サイトが決済情報の収集・処理に関わる要素を一つでも提供すれば、SAQ Aの適格性を失う可能性があります。
「iframeを使っているからSAQ A」ではありません。決済欄の周囲に見える自社ページが、カード情報へ影響するコードを読み込むかまで確認し、すべての適格条件を提出先と照合します。
キャッシュレス決済の使い分けで利用者側の違いを把握した後、本記事では事業者の決済実装をブラウザまで追います。手数料や入金条件だけで方式を選び、実装後の管理範囲を見落とす事故を防げます。
スクリプト台帳を実際の注文から作る
本番で実行されたコードを起点に、所有者、必要性、承認、完全性を結びます。
要件6.4.3は、消費者のブラウザで読み込まれ実行される決済ページスクリプトについて、承認を確認する方法、完全性を保証する方法、必要性の書面根拠を含む棚卸しを求めます。自社コードだけでなく、第三者やその先の第四者から届くスクリプトも対象になり得ます。
ソースコードリポジトリの一覧を台帳へ転記するだけでは足りません。タグマネージャー、A/Bテスト、広告計測、チャット、レビュー、住所補完、不正検知、同意管理は、管理画面から本番へ追加されることがあります。地域、端末、注文額、ログイン状態でだけ実行されるコードもあります。
台帳はリポジトリのファイル一覧ではなく、購入者のブラウザが実際に取得・実行したコードから作ります。
台帳にはスクリプト名、提供元URL、所有部門、用途、読み込むページ、カード入力への影響、データ送信先、承認者、完全性確認方法、更新方式、契約終了日、最終確認日、停止時の影響を持たせます。「マーケティング用途」では根拠になりません。「購入完了率の計測に使い、決済入力前のページでは読み込まない」のように、必要な場所と理由を限定します。
台帳に載っていることは許可ではありません。売上への効果が測れない、所有者が退職した、契約が終わった、同じ機能を別コードが担うスクリプトは、決済導線から外す候補です。
組込型金融の仕組みで扱う外部サービスとの責任分界は、決済ページでも不可欠です。広告・計測タグの追加を別案件にすると承認経路を迂回するため、売上効果とカード情報リスクを同じ変更票で確認します。
3Dセキュア用スクリプトを一律除外しない
PCI SSCのFAQは、一般的な3DS実装において、3DS Serverが発行会社等のACSやDirectory Serverに関連するURLを扱う信頼関係を前提に、3DS機能のためのスクリプトは要件6.4.3の検証対象外となる考え方を示しています。ただし、3DS以外の目的で動くスクリプトまで除外されません。
画面に「3Dセキュア」と表示されるかではなく、どのコンポーネントが誰との契約で何を実行するかを確認します。例外の判断根拠、ベンダー、機能、確認日を台帳へ残します。
承認・完全性・必要性を一つの公開ゲートにする
動作確認に加え、許可した版だけが必要な場所で動くかを合否にします。
スクリプトごとに三つの問いを通します。第一は、権限を持つ担当者が追加・更新を承認したかです。第二は、承認した内容と購入者が受け取る内容が一致するかです。第三は、決済ページで実行する業務上・技術上の必要性が残っているかです。
承認ではチケット番号だけでなく、変更差分、所有者、データ送信、委託先、テスト結果、戻し方を記録します。完全性確認は、Subresource Integrity、Content Security Policy、許可リスト、ハッシュ・署名、プロキシや監視製品による検証など、実装に合う方法を組み合わせます。外部スクリプトが予告なく変わる契約なら、更新を許容する条件と警報を別に設計します。
公開ゲートは「スクリプトが動くか」ではなく、「承認した版だけが必要な画面で動き、想定外の送信をせず、変更時に止められるか」を合否にします。
本番前には、通常購入、会員購入、ゲスト購入、保存カード、3DS成功・失敗、決済エラー、スマートフォンを通し、ネットワーク要求を保存します。キャンペーン開始直前にタグを追加する例外手続も、承認者と期限を決めます。
改ざん検知を通知件数ではなく対応時間で設計する
消費者が受け取るページの変化を見つけ、停止・調査・復旧へつなげます。
要件11.6.1は、消費者のブラウザが受け取る決済ページのHTTPヘッダーと内容について、無許可の変更を検出し担当者へ知らせる仕組みに焦点を当てます。監視対象はサーバー上のファイルだけではありません。CDN、タグ管理、外部配信、ブラウザでの動的変更を経て最終表示が変わるためです。
監視では、基準となるページ、ヘッダー、DOM、スクリプト、通信先を定めます。対象URLはトップページではなく、カード情報に至る全経路、埋め込み決済を含むページ、注文確認、エラー画面を含めます。多言語、スマートフォン、地域別配信があるなら基準を分けます。
警報は異常の証明ではありません。承認済み変更か、攻撃か、誤検知かを判定できる証拠へつなげます。
警報先を退職者のメールにすると、製品を導入しても守れません。一次受け、時間外連絡、重大度、決済停止権限、証拠保存、決済代行・CDN・制作会社への連絡、法務・個人情報担当への昇格を決めます。検知時刻、確認開始、封じ込め、復旧、再開承認を記録します。
警報の初動は三つに分けます。承認済みリリースなら変更票と実配信物を照合して基準を更新し、委託先の計画変更なら事前連絡、版、影響ページ、送信先を確認します。どちらにも一致しない変更は無許可として扱い、カード入力を止める判断へ進みます。「ベンダーが変えたと思う」で閉じず、誰が、いつ、どの版を許可したかが見つかるまで未解決にします。
改ざん検知のKPIはアラート数ではなく、無許可変更を何分で事実確認し、カード入力を止め、影響期間と注文を特定し、承認済み状態へ戻せるかです。
アタックサーフェス管理の一般手順へ、EC固有の決済停止、代替導線、注文照合、アクワイアラ・決済代行への連絡を足します。
頻度は七日に一度を免罪符にしない
PCI DSS 4.xの要件11.6.1には、少なくとも七日に一度、または対象リスク分析で定めた頻度という枠組みがあります。高頻度で変更され、攻撃から数分でカード情報を抜ける決済ページを週次だけで見ることが、自社リスクに合うとは限りません。
リリース時の検査、継続監視、日次の差分確認を組み合わせます。頻度を決めた理由、脅威、変更回数、検知能力、担当体制を対象リスク分析へ残します。
SAQ Aでも事業者側のページを放置しない
外部委託後に残るスクリプト対策、ASVスキャン、責任分界を確認します。
PCI SSCは2025年2月のFAQで、第三者の決済フォームを埋め込むSAQ A対象のEC事業者が、スクリプト攻撃を受けにくいことを確認する方法を説明しました。要件6.4.3・11.6.1の技術を自社または第三者が使う方法と、決済代行事業者から実装条件を守れば保護技術が含まれるとの確認を得る方法が示されています。
一方、リダイレクト方式や決済機能を完全に外部委託する方式には、この特定のスクリプト適格条件が同じ形で適用されないと説明されています。ただし、2026年6月更新のPCI SSC FAQは、SAQ AのECページについて、リダイレクトまたはiframeでもASVによる外部脆弱性スキャン要件があると明記しています。
外部委託は責任の消滅ではなく、守り方の変更です。決済代行のAOC、有効範囲、実装手順、責任分界、ASVスキャン、自社ページの変更管理を一つの証拠束で確認します。
取引先サイバーリスク管理で委託先の証拠、契約、事故連絡を確認し、本記事の決済代行・CDN・制作会社との責任分界へつなげます。
四週間で本番の実装を証拠化する
範囲確定、台帳、公開ゲート、改ざん演習を一つの証拠へまとめます。
第1週は決済方式と範囲を確定します。テスト注文を録画せず、HAR、DOM、スクリプト、通信先、ヘッダーを安全に保存し、カード番号など機微情報を除きます。契約する決済代行、アクワイアラ、自己問診票、提出期限を確認します。
第2週はスクリプト台帳を作り、所有者不明、用途不明、決済不要のコードを止めます。第三者コードの変更方式、完全性確認、契約、インシデント連絡を確認します。
第3週は公開ゲートと改ざん検知を設定し、通常変更、無許可スクリプト、外部送信先追加、CSP変更、タグ管理変更を試します。警報が担当者へ届き、承認記録と照合できるかを測ります。
第4週は模擬事故を行います。テスト環境で不正なコード変更を発生させ、検知、決済停止、証拠保全、影響調査、復旧、再開承認まで通します。注文を止める担当者が経営承認を待つ構造なら、重大時の権限を修正します。
KPIは、所有者付きスクリプト率、必要性根拠の期限切れ、無承認変更、決済ページの外部送信先数、リリース検査合格率、検知時間、一次確認時間、封じ込め時間、証拠欠落、ASVスキャン合格、模擬事故完了率を置きます。
PCI DSS対応の完成日は、問診票へ署名した日ではありません。実際の決済ページで無許可変更を起こし、検知、停止、調査、復旧、再開承認を証拠付きで通せた日です。
まとめ
決済ページのスクリプト対策は、セキュリティ部門だけの製品導入ではありません。EC運営、開発、広告、制作会社、決済代行、インフラが、購入者のブラウザへ何を届けるかを共同で管理する仕事です。
最初の一歩は監視製品の比較ではなく、テスト注文一件を最後まで通し、読み込まれた全スクリプト、送信先、所有者、必要性、承認、変更時の連絡を一枚の台帳へ結ぶことです。
参考情報
以下は2026年9月1日に確認したPCI SSCの一次情報です。
よくある質問
気になる質問を開くと、本文の重要点を短く確認できます。
Qカード情報を自社で保存しなければPCI DSSの対応は不要ですか？
A不要とは限りません。カード情報を保存・処理・送信するシステムだけでなく、その安全性へ影響できるECページや運用も対象になり得ます。決済方式と自己問診票の適格性をアクワイアラ等へ確認します。
Qiframe決済ならSAQ Aを使えますか？
Aiframeだけでは決まりません。カード情報の取得に関わる全要素が準拠した第三者から直接提供され、他のSAQ A適格条件も満たす必要があります。自社ページの要素が決済情報の収集・処理へ関わる場合は適格性が変わります。
Q要件6.4.3のスクリプト台帳には何を書きますか？
A提供元、所有者、用途、読み込むページ、承認者、完全性確認、必要性の書面根拠、データ送信先、更新方式、最終確認日、停止影響を記録します。実際のテスト注文で読み込まれるコードと照合します。
Q外部の広告タグやチャットも対象ですか？
A決済ページで読み込まれ、カード会員データの安全性へ影響し得るなら確認対象になり得ます。第三者・第四者コードを含め、場所、機能、送信先、必要性、完全性を評価します。
Q改ざん検知は週一回で十分ですか？
A規格上の頻度枠だけで自動的に十分とは決まりません。変更回数、攻撃時の影響、検知技術、担当体制を対象リスク分析で評価し、リリース時検査や継続監視を組み合わせます。
Q決済代行会社がPCI DSS準拠なら自社の証拠は不要ですか？
A委託先のAOCと対象サービス範囲を確認した上で、自社の安全な実装、変更管理、スクリプト対策、ASVスキャン、事故連絡、責任分界の証拠を残します。準拠事業者を使うことと、自社の実装が適格であることは別です。
