PCI DSS 6.4.3 と 11.6.1：決済ページスクリプトの管理と変更検知に関する準拠ガイド

本記事では、電子商取引のスクリプトセキュリティに関するこの二つの要件が加盟店の決済ページに求める具体的な内容を説明し、加盟店と決済サービス事業者の責任の境界を整理します。

要点：Requirement 6.4.3 は、加盟店に対し、決済ページ上のすべてのスクリプトを管理すること、すなわち承認済みであることを確認し、完全性を確保し、業務上または技術上の正当な理由を付したインベントリを維持することを求めています。Requirement 11.6.1 は、消費者のブラウザが受け取る決済ページのスクリプトと、セキュリティに影響する HTTP ヘッダーへの不正な変更を検知してアラートを発する仕組みを、少なくとも週 1 回、またはターゲットリスク分析で定めた頻度で運用することを求めています。両者は似ているように見えますが、6.4.3 は予防的コントロール（改ざんされたスクリプトが実行され続けるのを防ぐ）、11.6.1 は発見的コントロール（スクリプトの内容や HTTP ヘッダーの改ざんを検知した時点でアラートを発する）です。

決済ページの役割はカード番号の入力を受け付けることだけではありません。アクセス解析ツール、オンラインチャット、タグ管理システム、商品レビュー、さらに決済サービス事業者のコードも同時に読み込みます。これらはすべてスクリプトとしてユーザーのブラウザに送信され、一つずつ実行されます。

この柔軟性にはリスクが伴います。PCI SSC のガイダンスはこれを「e スキミング」と呼んでいます。決済ページ上のスクリプトが改ざんされたり、新たなスクリプトがひそかに埋め込まれたりして、顧客がカード情報を入力すると同時にそれを読み取り、外部へ送信する手口です。PCI DSS v4.0.1 は二つの要件でこれに対応しています。

自社に Requirement 6.4.3 と 11.6.1 は適用されるか？

Requirement 6.4.3 と 11.6.1 は PCI DSS v4.0 で新設され、2025 年 3 月 31 日から必須要件となっています。

要件の内容と評価時の確認事項

• 6.4.3：決済ページスクリプトの管理
  要件の内容：消費者のブラウザで実行される決済ページ上のすべてのスクリプトについて、承認済みであることを確認する方法と完全性を確保する方法を整備し、業務上または技術上の正当な理由を書面で付したインベントリを維持すること。
  テスト手順での確認事項：ポリシーと手順、スクリプトのインベントリ、システム構成。
• 11.6.1：変更の検知
  要件の内容：消費者のブラウザが受け取る決済ページのスクリプト、またはセキュリティに影響する HTTP ヘッダーに不正な変更が生じた際に、担当者へアラートを発する仕組みを導入すること。少なくとも週 1 回、またはターゲットリスク分析（Requirement 12.3.1）で定めた頻度で実施する。
  テスト手順での確認事項：仕組みの設定、監視対象のページ、監視結果。

さらに Requirement 12.10.5 により、この仕組みが発するアラートはインシデント対応計画に組み込まれます。

SAQ A を利用する加盟店の適格性基準

この二つの要件は SAQ A-EP、SAQ D、準拠報告書（ROC）に含まれています。2025 年 1 月改訂の SAQ A ではこれらの要件は記載されなくなり、代わりに SAQ A を完了する電子商取引加盟店は、次の二つの適格性基準を確認することが求められます（二つ目は新設）：

• 顧客のブラウザに届く決済ページ／フォームのすべての要素が、PCI DSS に準拠したサードパーティサービスプロバイダー（TPSP）／決済処理事業者のみから直接提供されていること。
• 加盟店が、自社の電子商取引システムに影響を及ぼし得るスクリプト攻撃に対して自社サイトが脆弱でないことを確認していること。

二つ目の基準は加盟店自身による表明であるため、加盟店はそれを具体的に説明できる根拠を備えておく必要があります。また、どの SAQ を利用するか（あるいは SAQ を利用できるか）は、引き続きアクワイアラが判断します。

PCI SSC FAQ 1588 によれば、上記二つ目の基準が適用されるのは、TPSP の決済フォームを自社ページに埋め込んでいる（例：iframe）加盟店のみです。顧客を TPSP へリダイレクトする加盟店や、決済プロセスを完全に外部委託している（例：決済リンクをメールで送付する）加盟店には適用されません。

FAQ 1588 はまた、加盟店が Requirement 6.4.3 と 11.6.1 に記載された技術を用いて、アカウントデータを狙うスクリプト攻撃から自社のウェブページを保護できること、そしてこれらの技術は加盟店自身または第三者が導入できることを示しています。

どのスクリプトが決済ページスクリプトに当たり、責任はどう分かれるのか

決済ページスクリプトとは？

PCI DSS の用語集は「決済ページスクリプト」を、決済ページ上で消費者のブラウザによって処理または解釈されるプログラミング言語の命令と定義しています。JavaScript はその一例であり、HTML と CSS は該当しません。Requirement 6.4.3 は、加盟店自身の環境から読み込まれるスクリプトに加え、アクセス解析タグが呼び込むベンダーのコードなど、第三者から読み込まれるスクリプトも対象とします。

PCI SSC FAQ 1592 によれば、第三者のスクリプト提供者が決済処理と無関係なスクリプトのみを提供し、かつそのスクリプトがカード会員データおよび機密認証データのセキュリティに影響しない場合、その提供者は Requirement 12.8、12.9 にいう TPSP とはみなされません。

埋め込みフォーム（iframe）における責任分界

決済フォームが iframe などの方法で加盟店のウェブページに埋め込まれている場合、要件の適用に関する注記に基づき、責任は次のように分かれます：

• 埋め込みフォームを含む加盟店のウェブページ上のスクリプトは、加盟店が管理・監視する。
• サービス事業者の埋め込みフォーム内部のスクリプトは、サービス事業者が責任を負う。

PCI SSC のガイダンスは、同じ考え方を「顧客をサービス事業者へリダイレクトする」スクリプトや、シングルページアプリケーション（SPA）の各画面にも適用しています。SPA では、顧客が画面を切り替えてもスクリプトの読み込みが続くためです。

予防と検知：Requirement 6.4.3 と 11.6.1 の役割分担

Requirement 6.4.3 は予防です。何が実行されているかを把握し、承認し、改ざんされていないことを確保します。Requirement 11.6.1 は発見的コントロールです。ブラウザに届く内容が変更されたことを察知し、対応を担当する担当者にアラートを発します。ただし、顧客のブラウザにソフトウェアをインストールすることを意味するものではありません。

PCI DSS は特定のツールを指定していません。公式ガイダンスはサブリソース完全性（SRI）、コンテンツセキュリティポリシー（CSP）、ページを読み込んで解析する外部監視などの手法を挙げ、どの仕組みも単独で要件を満たすのに十分とは限らないと注意を促しています。

埋め込みフォームを適用除外と誤解しない

埋め込み型の決済フォームを使えば加盟店が管理すべき範囲は小さくなりますが、加盟店自身のページは引き続き対象範囲に含まれます。この二つの要件に関する PCI SSC の情報補足資料は、第三者の決済フォームを埋め込んでも、加盟店の埋め込み元ページ（親ページ）が完全に対象範囲外になるわけではなく、Requirement 6.4.3 と 11.6.1 が適用外になるわけでもないとしています（SAQ A の対象となる加盟店は、代わりに適格性基準で確認します）。親ページ上のスクリプトは、フォーム周辺の内容や、読み込まれるフォームそのものを変更し得ます。Requirement 6.4.3 のガイダンスは、親ページの CSP を利用して決済フォームの読み込み元を制限することを推奨しています。

決済ページスクリプト管理の核心は、ページ上で実行されているすべてのスクリプトについて、なぜそのスクリプトが必要なのか、誰が承認したのか、そしてスクリプトが変更されたときにどれだけ早くアラートを受け取り対応を開始できるのかを、加盟店が明確に把握できているかどうかにあります。埋め込み型フォームは対象範囲を狭めますが、自社ページの管理に代わるものではありません。どの SAQ が適用されるか、スクリプトのインベントリが網羅的か、現在の監視が Requirement 11.6.1 を満たしているかが不明な場合は、評価の前に PCI DSS に精通した QSA へ相談することをお勧めします。

用語解説

• 加盟店（Merchant）：アクワイアラと契約し、カード決済を受け付ける事業者。PCI DSS でいう merchant。
• TPSP（Third-Party Service Provider、サードパーティサービスプロバイダー）：加盟店に決済処理などのサービスを提供する外部事業者。
• SAQ（Self-Assessment Questionnaire、自己問診票）：加盟店が自社の決済環境に応じて、アクワイアラに準拠を示すための問診票。
• ROC（Report on Compliance、準拠報告書）：認定審査人（QSA）が作成する PCI DSS の評価報告書。
• 決済ページスクリプト：決済ページ上で消費者のブラウザによって処理または解釈されるプログラミング言語の命令。JavaScript など。
• e スキミング（e-skimming）：決済ページのスクリプトを埋め込み・改ざんし、顧客がカード情報を入力する際に読み取って外部へ送信する攻撃手法。
• SRI（Subresource Integrity、サブリソース完全性）：ブラウザが事前に宣言されたハッシュ値を用いて、外部スクリプトファイルが改変されていないことを検証する仕組み。
• CSP（Content Security Policy、コンテンツセキュリティポリシー）：ブラウザがスクリプトなどのリソースをどの提供元から読み込めるかを、サイト側が宣言する仕組み。
• iframe：ウェブページ内に別の独立したページの内容を埋め込む要素。決済サービス事業者のフォームの埋め込みによく使われる。
• 親ページ（Parent Page）：iframe を埋め込んでいる外側の加盟店ページ。
• SPA（Single-Page Application、シングルページアプリケーション）：画面の切り替え時にページ全体を再読み込みせず、スクリプトで画面を動的に更新するサイト構成。
• ターゲットリスク分析：Requirement 12.3.1 に基づき、事業体が自ら分析して特定の要件の実施頻度を定めるもの。

よくある質問（FAQ）

Q1：決済サービス事業者のフォームを iframe で埋め込んでいれば、スクリプトを管理する必要はありませんか？
フォーム内部のスクリプトは決済サービス事業者の責任ですが、加盟店のページ上のスクリプトは引き続き加盟店が管理・監視する必要があります。フォームを埋め込んでも、加盟店の親ページが完全に対象範囲外になるわけではありません。SAQ A を利用する加盟店は、代わりに適格性基準で確認します（次の質問を参照）。

Q2：SAQ A を利用する加盟店も対応が必要ですか？
SAQ A にはこの二つの要件は記載されていませんが、加盟店は適格性基準を確認する必要があります。このうち「サイトがスクリプト攻撃に対して脆弱でない」という基準は、FAQ 1588 によれば TPSP のフォームを埋め込んでいる（iframe など）加盟店にのみ適用され、リダイレクト方式や決済を完全に外部委託している加盟店には適用されません。この確認は加盟店自身の表明であり、根拠が必要です。どの SAQ を利用するかはアクワイアラが判断します。

Q3：Requirement 11.6.1 はどのくらいの頻度で実施すべきですか？頻度を自社で決められますか？
既定は少なくとも週 1 回です。加盟店が自ら実施したターゲットリスク分析（Requirement 12.3.1）に基づいて別の頻度を定めることもできますが、その根拠として文書化されたリスク分析が必要であり、評価ではその分析と実際の運用が一致しているかが確認されます。

Q4：CSP や SRI の使用は必須ですか？
必須ではありません。PCI DSS はツールを指定しておらず、PCI SSC のガイダンスは SRI、CSP、外部監視などを例として挙げるにとどまり、単一の仕組みでは十分でない場合があると注意を促しています。

Q5：アクセス解析ツールの提供者は TPSP に当たりますか？
FAQ 1592 によれば、第三者のスクリプト提供者が決済処理と無関係なスクリプトのみを提供し、かつそのスクリプトがカード会員データおよび機密認証データのセキュリティに影響しない場合、Requirement 12.8、12.9 にいう TPSP とはみなされません。この二つの条件は加盟店自身が確認します。

参考資料

出典：PCI DSS v4.0.1（Requirement 6.4.3、11.6.1、12.8、12.9、12.10.5 および用語集）、PCI SSC 情報補足資料『Payment Page Security and Preventing E-Skimming – Guidance for PCI DSS Requirements 6.4.3 and 11.6.1』（2025 年発行）、PCI DSS v4.0.1 対応の SAQ A（2025 年 1 月改訂版）。いずれも PCI SSC ドキュメントライブラリから入手できます。要件の原文は規則として記述されており、ガイダンスと明記された内容は推奨事項です。