PCI DSS 6.4.3 and 11.6.1: A Practical Payment-Page Script Checklist
By CellWall Security Research | Published September 9, 2026 | Client-Side Security | 16 min read
On this page
- What Do Requirements 6.4.3 and 11.6.1 Ask You to Operate?
- Step 1: Establish the Payment-Page Scope
- Step 2: Build a Defensible Script Inventory
- Step 3: Confirm Authorization
- Step 4: Choose and Document an Integrity Method
- Step 5: Detect Unauthorized Payment-Page Changes
- Step 6: Make Alerts Actionable
- The Practical Readiness Checklist
- Evidence to Prepare for an Assessment
- Important SAQ A Distinction
- Common Failure Patterns
- Where SiteWall Fits
- Frequently Asked Questions
- Operate the Checklist Between Assessments
Reading Progress
0%
16 min left
PCI DSS Requirement 6.4.3 focuses on managing payment-page scripts through authorization, integrity assurance, and a justified inventory. Requirement 11.6.1 focuses on detecting unauthorized changes to security-impacting HTTP headers and payment-page contents as received by the browser. Together, they turn browser-side payment security into an ongoing operating process.
This guide translates those outcomes into work that security, engineering, e-commerce, and compliance teams can assign and verify. It is based on PCI DSS v4.0.1 and PCI Security Standards Council guidance available at publication time.
A checklist or security product cannot determine PCI DSS compliance. Confirm scope, applicability, assessment evidence, and validation responsibilities with your Qualified Security Assessor, acquirer, payment brand, or other compliance-enforcing entity.
What Do Requirements 6.4.3 and 11.6.1 Ask You to Operate?
| Requirement | Operational outcome | Questions your evidence should answer |
|---|---|---|
6.4.3 | Payment-page scripts are inventoried, justified, authorized, and subject to an integrity method. | Which scripts execute, why are they necessary, who approved them, and how is their integrity assured? |
11.6.1 | A change- and tamper-detection mechanism evaluates security-impacting HTTP headers and payment-page contents received by the browser and alerts personnel to unauthorized modification. | What changed, when was it observed, was it authorized, who received the alert, and what happened next? |
The controls reinforce each other. A current inventory gives change detection an approved baseline. Runtime observations can reveal an unlisted script or altered behavior that sends the team back through authorization and integrity review. This is why third-party JavaScript monitoring should connect to governance rather than operate as an isolated alert feed. The Magecart and web-skimming guide shows the browser-side attack chain these controls are designed to disrupt and expose.
Step 1: Establish the Payment-Page Scope
Do not begin by exporting every script on the public website. Begin with the pages, components, and browser contexts that capture account data or can affect the security of the payment process. Include the entity-controlled page around an embedded payment form when scripts on that page could influence the experience or its security.
Map payment journeys
Record every checkout path, payment method, domain, subdomain, locale, device layout, authenticated state, and redirect or embedded-form variation.
Identify browser boundaries
Document which code runs in the merchant page, which code runs inside third-party frames, and how parent pages, frames, redirects, and single-page application routes interact.
Include security-impacting pages
Review pages and components that can influence payment security, not only the moment when a card field is visible. Confirm the resulting boundary with the applicable PCI DSS validation process.
Observe representative states
Capture anonymous and authenticated sessions, consent states, promotions, error paths, alternative payment methods, and regional variations that may load different scripts.
Assign ownership
Name the business owner, technical owner, security reviewer, and responder for each in-scope journey and integration.
A cosmetic route change may not create a new browser document. Scripts and headers loaded earlier can remain relevant when the application later renders checkout. Test the browser architecture you actually deliver instead of assuming URL paths create isolation.
Step 2: Build a Defensible Script Inventory
A useful inventory is an authorization register, not a list of URLs. It connects each observed resource to a provider, owner, business purpose, approval record, integrity method, and expected scope. It should also preserve the initiator chain because one approved tag may load several additional resources indirectly. Use the practical third-party JavaScript inventory template to establish the broader register, then apply the payment-page evidence requirements below.
| Inventory field | Why it matters | Example evidence |
|---|---|---|
Script and resource identity | Distinguishes a specific asset from a general vendor relationship. | Observed URL, host, path, version, hash, first seen, and last seen |
Provider and internal owner | Creates accountability for review, renewal, and removal. | Vendor, business owner, engineering owner, contract or ticket reference |
Written justification | Explains why the script is necessary on the payment journey. | Specific function and pages; avoid labels such as “marketing” without context |
Loading relationship | Reveals scripts introduced by tag managers, loaders, frames, or dependencies. | Parent resource, initiator, frame, tag-manager container, or application bundle |
Authorization status | Connects the observed script to a deliberate decision. | Approver, decision date, approved scope, review date, and change record |
Integrity method | Documents how unauthorized modification is prevented or detected. | SRI, controlled hosting, allowlist, content comparison, runtime monitoring, or another assessed method |
Expected behavior | Makes behavioral drift reviewable. | Form access, DOM access, storage, browser APIs, destinations, and expected update cadence |
Keep first-party bundles in the inventory when they execute on an in-scope payment page. A familiar hostname does not prove that the delivered code is authorized, unchanged, or unable to load additional resources.
Inventory completeness
Scripts written directly into page templates and application bundles.
Resources injected by tag managers, consent platforms, A/B testing tools, chat, analytics, fraud services, and payment integrations.
Nested dependencies and dynamically created scripts observed during representative payment journeys.
Scripts that appear only for selected regions, devices, users, consent states, or transaction outcomes.
Governance record
A specific written business or technical justification for every necessary script.
Named internal ownership and a traceable authorization decision.
The approved pages, conditions, behaviors, destinations, and integrity method.
A removal or reauthorization process for unknown, orphaned, or materially changed scripts.
Step 3: Confirm Authorization
Authorization needs a repeatable decision method. A script is not authorized merely because it has been present for years, belongs to a known provider, or appears in a tag manager. The observed asset and its purpose should match an accountable approval record.
Request
The owner documents the script, provider, purpose, required pages, data access, network destinations, deployment method, and operational dependency.
Assess
Security and engineering review necessity, page scope, supplier risk, reachable data, browser capabilities, integrity options, and safer alternatives.
Approve
An authorized role records the decision, allowed scope, conditions, evidence, and expiration or review date.
Deploy
The team releases the approved configuration through controlled change management and verifies what users actually receive.
Reconcile
Observed scripts are compared with the authorization register. Unknown or mismatched resources are investigated rather than automatically accepted into the baseline.
Measure the time from first observation to ownership and disposition. Inventory count is useful, but an unresolved script with payment-page access is the governance risk that needs an accountable decision.
Step 4: Choose and Document an Integrity Method
Integrity assurance should match how the resource is delivered. A version-pinned, static cross-origin library can often use Subresource Integrity. A dynamic vendor tag that changes at the same URL needs a different assessed method, such as controlled hosting, allowlisting combined with change review, content comparison, or runtime behavior monitoring.
| Delivery pattern | Possible integrity approach | Operational limitation to record |
|---|---|---|
Static, versioned external file | SRI with a pinned URL and controlled update process | A legitimate vendor update fails until the approved hash is changed |
Self-hosted application bundle | Protected source and build pipeline, artifact provenance, deployment controls, and delivered-content comparison | Pipeline assurance does not by itself prove every browser received the expected response |
Dynamic third-party tag | Approved provider and destination controls, content or behavior baselines, and change monitoring | A hostname allowlist cannot determine whether trusted code changed maliciously |
Tag-manager-delivered code | Access control, publishing approvals, container versioning, observed inventory reconciliation, and runtime monitoring | The container can change without an application deployment |
Embedded payment component | Merchant-page controls plus documented responsibility and assurance from the payment provider for its embedded content | Parent-page scripts may still affect payment security; scope depends on the architecture |
CSP can constrain allowed sources and other browser behaviors. SRI can bind an eligible external resource to expected bytes. Neither replaces inventory, written justification, authorization, change review, or alert response, and neither fits every dynamic script.
Step 5: Detect Unauthorized Payment-Page Changes
Requirement 11.6.1 is concerned with what reaches the consumer browser. Monitor the relevant HTTP headers and payment-page contents, including script changes, additions, and deletions. The comparison needs enough context to distinguish approved releases from unauthorized modification and enough coverage to observe representative page states.
HTTP headers
Security-impacting headers are collected from the response received for each representative payment-page variant.
Missing, added, or changed header values are compared with an approved baseline.
Redirects, CDN behavior, cache variants, and regional delivery paths are represented where they can change the response.
Payment-page contents
Added, removed, and modified scripts and executable content are detected.
Dynamically loaded resources and tag-manager changes are observed during relevant user journeys.
The record preserves the page, time, initiator, frame, provider, prior state, new state, and affected sessions where available.
Detection cadence
The mechanism operates at least once every seven days or at the periodic frequency supported by the applicable targeted risk analysis, where permitted by the assessment approach.
Risk-triggered checks also run after releases, vendor changes, tag-manager publications, incidents, and material payment-flow changes.
Continuous or session-based monitoring is evaluated where weekly sampling would leave unacceptable exposure or miss conditional behavior.
A timestamped comparison can prove that a specific page state and response were evaluated and that a difference was observed. It does not prove universal coverage, explain intent, establish that every user received the same content, or determine compliance without the surrounding scope, control operation, and assessment evidence.
Step 6: Make Alerts Actionable
| Alert context | Triage question | Possible next action |
|---|---|---|
New script or provider | Is it in the authorization register, and what initiated it? | Contain if necessary; identify the owner and reconcile with the approved inventory |
Existing script changed | Was there an approved vendor or application release? | Compare content, dependencies, behavior, destinations, and release evidence |
Security header changed | Did the change weaken an approved restriction or reflect expected delivery variation? | Restore the approved value, validate CDN or deployment paths, and assess exposure |
New form or payment-field access | Does the script require this capability for its documented purpose? | Restrict or disable the integration and investigate affected sessions |
New outbound destination | Is the destination approved and consistent with the provider's purpose? | Block or contain where supported; preserve network and initiator evidence |
Script removed or failed | Was removal approved, or did a critical payment control stop loading? | Confirm the change record and evaluate security and checkout impact |
Preserve
Save the delivered page state, headers, script identity or content signal, loading chain, destinations, timestamps, and affected journey before evidence disappears.
Classify
Compare the observation with the authorization register, deployment records, vendor notices, and expected behavior.
Contain
Use the safest available option: disable a tag, block a provider or destination, restore headers, roll back a release, or temporarily alter the payment journey.
Investigate
Determine cause, exposure window, affected sessions, accessed data, outbound communication, and whether incident-response or notification procedures apply.
Close
Record the decision, remediation, validation, approver, residual risk, and any required update to the inventory or baseline.
Connect the workflow to your client-side incident response process before the first high-severity alert. A detection tool without an owner, containment path, and evidence-retention procedure creates notification without control.
The Practical Readiness Checklist
Scope and ownership
Every payment journey and browser boundary is documented.
Merchant and third-party responsibilities are recorded for parent pages, frames, redirects, and hosted components.
Each in-scope integration has business, engineering, security, and response ownership.
Requirement 6.4.3 operations
The inventory reflects scripts actually loaded and executed in representative browser journeys.
Every script has a specific written justification and traceable authorization record.
An integrity method is documented and operated for every script delivery pattern.
Unknown, orphaned, and materially changed scripts enter an exception, removal, or reauthorization workflow.
Requirement 11.6.1 operations
Security-impacting HTTP headers and payment-page contents are evaluated as received by the browser.
The mechanism identifies unauthorized changes, additions, and deletions and alerts responsible personnel.
The evaluation frequency is documented and supported by the applicable requirement or targeted risk analysis.
Representative dynamic, regional, consent, authentication, and payment-method states are covered.
Response and evidence
Alerts include page, time, resource, prior state, new state, initiator, provider, and authorization context.
Responders can preserve evidence and disable, block, or roll back a risky change without improvising access.
Tickets show triage, decisions, remediation, validation, closure, and approval.
Samples demonstrate that the controls operated over the assessment period, not only on the interview date.
Evidence to Prepare for an Assessment
| Evidence set | Useful contents |
|---|---|
Scope record | Payment-flow diagrams, domains, pages, frames, variants, responsible parties, and assessment rationale |
Script authorization register | Observed scripts, owners, justifications, approvals, page scope, dependencies, behaviors, and integrity methods |
Control configuration | Detection coverage, baselines, header rules, schedules, targeted risk analysis where applicable, alert routing, and retention settings |
Operating samples | Representative evaluations, approved and unauthorized changes, alerts, investigations, and reconciliations across the review period |
Change records | Application releases, tag-manager versions, vendor notices, approvals, SRI changes, and post-deployment verification |
Response evidence | Triage timestamps, ownership, containment, root cause, affected scope, remediation, validation, and closure |
Third-party assurance | Responsibility matrices, contracts, attestations where relevant, implementation instructions, and provider communications |
Make release records easy to correlate with browser observations. Include the deployment identifier, affected payment routes, expected script and header changes, approval ticket, and post-release verification in one traceable record.
Important SAQ A Distinction
PCI SSC removed Requirements 6.4.3 and 11.6.1 from the January 2025 SAQ A revision. It also added an eligibility criterion requiring applicable merchants to confirm that their site is not susceptible to script attacks that could affect their e-commerce systems. This change applies to that validation questionnaire; it did not remove the two requirements from PCI DSS v4.0.1.
Do not infer your eligibility or obligations from the integration label alone. An embedded form, redirect, single-page application, merchant-controlled parent page, and third-party script can create different responsibilities. Confirm which assessment instrument and evidence apply with the organization that manages your compliance program.
The revised SAQ A still requires an eligibility confirmation concerning script-based attacks. PCI SSC states that techniques from Requirements 6.4.3 and 11.6.1 may be used to support that confirmation, whether operated by the merchant or an appropriate third party.
Common Failure Patterns
| Failure pattern | Why it falls short | Better operating practice |
|---|---|---|
Spreadsheet created just before the assessment | It may not reflect scripts users actually received or demonstrate ongoing operation. | Continuously reconcile observed resources with the authorization register and preserve history |
One approval for an entire vendor | A provider may deliver multiple assets with different purposes, pages, dependencies, and privileges. | Authorize the relevant scripts, scope, purpose, and expected behavior |
CSP allowlist treated as integrity proof | An allowed origin can still serve compromised or unexpectedly changed code. | Layer source restrictions with an integrity method, change context, and behavior monitoring |
Homepage-only scanning | Checkout variants and conditional scripts may never execute there. | Evaluate representative payment journeys and states |
Every change automatically approved into the baseline | A malicious modification can become the new normal before review. | Quarantine unexplained drift until an accountable owner authorizes or removes it |
Alert closed because the vendor is known | Trusted providers and accounts can be compromised or misconfigured. | Verify the observed change against purpose, release evidence, behavior, and destinations |
Where SiteWall Fits
SiteWall supports PCI DSS payment-page security operations by discovering browser resources and providers, preserving observed loading and behavior context, highlighting changes and policy findings, and organizing evidence around client-side governance workflows.
Teams can use scheduled discovery and live-session observations to compare the delivered payment experience with an approved baseline. Depending on deployment mode and configured policies, SiteWall can also support controls over resources, browser capabilities, providers, and network behavior. Coverage and compliance conclusions remain dependent on architecture, configuration, operational process, scope, and assessor evaluation.
Turn Payment-Page Observations Into Reviewable Evidence
Evaluate SiteWall on representative payment journeys to see how resource inventory, browser behavior, change context, policy findings, and evidence workflows fit your PCI DSS operating model.
Frequently Asked Questions
What does PCI DSS Requirement 6.4.3 require for payment-page scripts?
Requirement 6.4.3 calls for methods to confirm that each payment-page script is authorized, assure the integrity of each script, and maintain an inventory with written justification for why each script is necessary. The exact implementation and assessment evidence depend on the payment architecture and validation approach.
What does PCI DSS Requirement 11.6.1 monitor?
It addresses change and tamper detection for security-impacting HTTP headers and payment-page contents as received by the consumer browser. The mechanism should identify unauthorized modification, including relevant changes, additions, and deletions, and alert responsible personnel.
How often must the 11.6.1 mechanism evaluate payment pages?
PCI DSS v4.0.1 specifies at least once every seven days or periodically according to the entity's targeted risk analysis where that option and assessment approach apply. Confirm the required cadence and supporting evidence with your assessor or compliance-enforcing entity.
Does an embedded payment iframe remove the merchant page from consideration?
Not automatically. Scripts inside the embedded payment form may be the payment processor's responsibility, while scripts in the merchant-controlled parent page can still affect payment security. Architecture, iframe boundaries, script loading, and the applicable validation method must be assessed together.
Are Requirements 6.4.3 and 11.6.1 still part of PCI DSS after the SAQ A change?
Yes. PCI SSC removed them from the January 2025 SAQ A revision, not from PCI DSS v4.0.1. The revised SAQ A also added an eligibility criterion related to susceptibility to script attacks affecting e-commerce systems.
Is Subresource Integrity enough for Requirement 6.4.3?
SRI can be an effective integrity control for eligible static, versioned resources, but it does not provide written justification, authorization, full inventory coverage, dynamic-script assurance, tamper-response workflow, or universal payment-page monitoring by itself.
Does a PCI DSS payment-page monitoring product make a company compliant?
No. A product can support technical controls and evidence, but compliance depends on correctly scoped, configured, operated, documented, and assessed controls across the organization. The applicable assessor or compliance-enforcing entity determines validation expectations.
Operate the Checklist Between Assessments
The useful outcome is not a perfect spreadsheet on assessment day. It is a controlled payment-page environment where the team can explain which scripts execute, why they are necessary, who authorized them, how integrity is assured, what changed in the browser, and how unauthorized changes are handled.
Start with one representative payment journey. Establish its browser boundaries, reconcile the observed script inventory, connect each resource to authorization and integrity evidence, validate header and content monitoring, and run one alert through the complete response workflow. Then expand coverage without weakening ownership or evidence quality.
Authoritative Sources and Related Guides
Continue exploring
Read the practical guides that clarify the surrounding risks, controls, and evidence.
Explore the client-side security hub
Product Updates
Own What Happens in the Browser: Introducing SiteWall
Discover, control, and prove what third-party providers and resources do in the browser with SiteWall client-side security and compliance evidence.
Client-Side Security
Third-Party JavaScript Monitoring: Uptime, Updates, and Behavioral Drift
Learn how to monitor third-party script availability, performance, update frequency, dependency changes, and unexpected behavior in the browser.
Client-Side Security
Types of Client-Side Attacks: 12 Browser Threats to Know
Explore 12 common client-side attacks, how they reach the browser, what warning signs to investigate, and which controls can reduce the risk.