by Source Defense
If you have assessed enough e-commerce environments, you have seen the pattern: most clients can explain PCI DSS 4.0.1 Requirements 6.4.3 and 11.6.1 at a high level. Where it gets interesting is when you ask for proof.
“Do you have an inventory of payment page scripts?” becomes “Which scripts actually execute in the customer’s browser today, including the ones introduced by tag managers and third parties?” “Do you monitor for tampering?” becomes “Show me an alert tied to a real change in security-impacting HTTP headers or script content as the browser received it.”
That gap between policy and evidence is exactly what these requirements are meant to fix. Modern payment pages are assembled dynamically in the browser, often pulling active content from multiple locations, and that the best place to detect unauthorized changes is in the consumer’s browser as the page is constructed and scripts execute.
The PCI Security Standards Council has even published dedicated guidance for 6.4.3 and 11.6.1, which is a polite way of acknowledging that implementation and assessment can get messy in the real world.
This post is built for that moment in an assessment. We translate each part of 6.4.3 and 11.6.1 into an inspection-ready checklist: what to validate, what evidence to request, and the failure modes that look compliant until you try to verify them end to end.
That framing is the key to a clean validation approach:
- 6.4.3 is preventative: script authorization, integrity, inventory, and justification for scripts that load and execute in the consumer’s browser.
- 11.6.1 is detective: change and tamper detection for security-impacting HTTP headers and script contents of payment pages, as received by the consumer browser, with timely alerting.
Step 0: Lock Scope Before You Touch Controls
Confirm what counts as a “payment page”
PCI DSS defines a payment page as a web-based user interface with form elements intended to capture or submit account data, including iframes and multi-iframe implementations.
QSA scope checks
- Identify every URL and template involved in the payment flow, not just the final “card entry” page.
- Confirm where payment UI is rendered (native page, iframe, multiple iframes).
- If an embedded payment form is provided by a TPSP/payment processor, confirm which parts remain the merchant’s responsibility versus the TPSP’s. The PCI DSS guidance notes that entities should expect evidence from the TPSP that the TPSP meets these requirements, consistent with the TPSP’s assessment and Requirement 12.9.
Requirement 6.4.3 Inspection Checklist
Requirement text
“All payment page scripts that are loaded and executed in the consumer’s browser are managed” with (1) authorization, (2) integrity, (3) inventory and written business/technical justification.
Defined Approach testing procedures
- 6.4.3.a Examine policies and procedures for defined processes across all elements.
- 6.4.3.b Interview personnel and examine inventory records and system configurations to verify operation.
6.4.3 Checklist A: Script Inventory
What to inspect
- Inventory includes every script loaded and executed on each payment page, as rendered in the consumer browser.
- Inventory includes scripts from third and fourth parties (not just first-party).
- Inventory is mapped to specific pages/templates in the payment flow (not a single global list).
What good evidence looks like
- A versioned inventory record that includes, at minimum:
- Script name/identifier
- Source (domain/path, first-party vs third-party)
- Where it runs (page(s) or template(s))
- Owner (internal business/technical owner)
- Change history (when it appeared/changed)
Red flags
- Inventory is collected from server-side code repositories only (missing runtime-injected scripts).
- Inventory does not identify scripts loaded via tag management systems (even though PCI DSS calls these out as common).
6.4.3 Checklist B: Written Business or Technical Justification (per script)
PCI DSS requires an inventory with written business or technical justification for why each script is necessary.
What to inspect
- Each script has a justification that is specific and reviewable (not just “analytics”).
- Justification aligns to the actual page context (checkout vs post-purchase).
- Justification is tied to a named owner who can defend it during interviews.
Good evidence
- A clear, understandable response related to each script which demonstrates the root of this requirement – that the organization is paying attention, discussing what runs on their site and recognizes that someone must be accountable for this justification.
Red flags
- “Nice to have” scripts on payment pages with no clear business case.
- Scripts whose justification is “required by vendor” with no supporting detail.
6.4.3 Checklist C: Authorization (prove scripts are explicitly approved)
PCI DSS requires a method to confirm each script is authorized. It also notes authorization may be manual or automated workflows, and where pre-authorization is impractical, it should be confirmed as soon as possible after the change.
What to inspect
- A documented authorization process exists (policy and procedure).
- Authorization includes scripts introduced by marketing, UX, or tag management, not just engineering.
- Evidence exists for recently added/changed scripts (tickets, approvals, workflow logs).
Good evidence
- Change-management records showing who approved what, when, and why.
Red flags
- “We authorize vendors annually” (vendor approval is not script authorization).
- Authorization exists but does not cover scripts loaded indirectly (fourth-party and tag manager chains).
6.4.3 Checklist D: Integrity (prove scripts have not been tampered with)
PCI DSS requires a method to assure integrity of each script. While PCI DSS provides examples of integrity approaches, including Subresource Integrity (SRI) and Content Security Policy (CSP), we, along with experts in PCI Forensic Investigations, others in the vendor community and dozens of others across the ecosystem have warned that they should NOT be considered effective controls for eSkimming security.
SRI only verifies that a fetched resource matches a known hash which is hard to maintain for frequently changing, dynamically generated, or runtime-injected scripts, and CSP primarily limits where scripts can load from or which nonced/hashed scripts may run, but it does not validate that an allowed script has not been compromised or is behaving safely once it executes.
In practice, CSP is often loosened to avoid breaking functionality (broad allowlists, report-only, unsafe-inline), and “strict” patterns can extend trust to additional scripts via mechanisms like strict-dynamic, which increases the blast radius if a trusted script is abused.
Purpose-built script management systems, by contrast, can unify inventory, authorization and integrity assurance and add enforcement that can actually prevent malicious script execution, which is why PCI lists them alongside CSP and SRI as an integrity mechanism option. And because PCI also recognizes that traditional change detection often cannot see what is assembled dynamically, the “only place” to detect unauthorized changes and skimmer-like indicators is in the consumer browser, which is exactly where these systems are designed to operate.
What to inspect
- Integrity controls are documented, implemented, and demonstrably applied to in-scope scripts.
- The method works for the client’s real environment (dynamic scripts, frequent updates, tag managers).
- The entity can explain how integrity is handled for third-party scripts that change frequently.
Good evidence
- Authorization audit trail: Tickets/workflow logs showing who approved each script (and recent changes), tied back to the inventory.
- Integrity + monitoring proof: Config export plus monitoring run history and sample alerts showing detection of unauthorized header/script changes as received by the browser (weekly or per risk analysis).
Red flags
- Integrity is “handled by the CDN” with no linkage to payment page scripts.
- Integrity is implemented only for a subset of scripts, with no rationale.
6.4.3 Outcome check
PCI DSS states the customized approach objective as: unauthorized code cannot be executed in the payment page as rendered in the consumer’s browser.
Practical QSA validation question:
“If a new script shows up tomorrow in the payment flow, can the client prove it will not execute without being authorized, or that they will catch it immediately and have compensating controls?”
Requirement 11.6.1 Inspection Checklist
Requirement text
A change- and tamper-detection mechanism is deployed to alert personnel to unauthorized modification (including indicators of compromise, changes, additions, deletions) to security-impacting HTTP headers and script contents of payment pages as received by the consumer browser. The mechanism evaluates received headers and pages, and runs at least weekly or at a risk-defined frequency based on targeted risk analysis per 12.3.1.
Defined Approach testing procedures
- 11.6.1.a Examine system settings, monitored pages, and monitoring results.
- 11.6.1.b Verify configuration aligns to all elements.
- 11.6.1.c If using entity-defined frequency, examine targeted risk analysis for 12.3.1 alignment.
- 11.6.1.d Verify the frequency is weekly or risk-defined.
11.6.1 Checklist A: Coverage
What to inspect
- Mechanism explicitly monitors security-impacting HTTP headers and script contents of payment pages (as received by the consumer browser).
- Coverage includes every in-scope payment page identified in Step 0.
- Monitoring is performed from the perspective that matters: what the consumer browser actually receives and executes.
Good evidence
- Baselines or known-good snapshots for headers
Red flags
- Monitoring checks only the origin server files (missing runtime-assembled content).
- Monitoring checks only page HTML, not scripts or headers.
11.6.1 Checklist B: Frequency (weekly or risk-based, but not “whenever we remember”)
- At least weekly, or
- Periodically at a frequency defined by targeted risk analysis (12.3.1).
What to inspect
- If weekly: proof of weekly execution (logs, reports).
- If risk-based: targeted risk analysis exists and clearly justifies the chosen frequency.
Good evidence
- Scheduler logs, monitoring run history, and alerting test results.
Red flags
- Risk-based frequency with no documented analysis.
- Frequency defined, but monitoring routinely fails or runs intermittently.
11.6.1 Checklist C: Alerting and response (who gets notified, and what happens next)
11.6.1 is explicit about alerting personnel to unauthorized modification, including indicators of compromise.
What to inspect
- Alerts route to a monitored channel (ticketing, SIEM, on-call).
- There is an operational process to review and respond to alerts.
- Evidence exists of alert testing (not just “it should alert”).
Good evidence
- Sample alerts for real or test changes, with response actions and closure notes.
- Clear ownership (security operations, appsec, eCommerce ops).
Red flags
- Alerts go to an unmonitored inbox or a single person.
- Alerts lack enough detail to support triage (no “what changed” context).
11.6.1 Checklist D: Mechanism types (what PCI DSS explicitly recognizes)
PCI DSS gives examples of detection and reporting mechanisms, including:
- CSP violation reporting (report-to/report-uri)
- Detecting changes to CSP itself
- External monitoring that requests and analyzes received pages (synthetic monitoring)
- Embedded tamper-resistant/tamper-detection script that can alert and block when malicious behavior is detected
- Reverse proxies and CDNs that detect changes and alert personnel
It also clarifies the intent is not to install software in consumers’ systems/browsers, but to use techniques like those listed.
QSA validation tip
Do not evaluate the mechanism by brand name. Evaluate it by whether it produces verifiable evidence of: monitored pages, monitored headers, monitored script contents, alerting, and run frequency.
11.6.1 Outcome check
PCI DSS states the objective as timely alerting for added skimming code/techniques and prompt alerting if anti-skimming measures are removed. So a practical validation question could be: “If a skimmer is injected, or a control is removed, will the client know in time to matter, and can they prove it with alert evidence?”
A Simple Evidence Package QSAs Can Ask For
If you want clients to pass cleanly, ask for a standardized evidence bundle. It reduces friction and prevents “we’ll pull that later” sprawl.
For 6.4.3
- Written justification per script.
- Authorization workflow artifacts (tickets, approvals, change records).
- Integrity control proof (SRI/CSP configs, tool reports, enforcement evidence).
For 11.6.1
- Monitoring run history showing weekly or risk-based cadence.
- Alert samples and incident workflow evidence.
- Targeted risk analysis (only if not weekly).
Common Failure Patterns QSAs Should Watch For
- Integrity controls that break in modern web environments
PCI DSS acknowledges scripts can be altered and can load additional external scripts (including via tag management). If the integrity method cannot handle that reality, you will see drift. - 11.6.1 monitoring done “on the server” instead of “as received by the browser”
PCI DSS is explicit that browser-side assembly is where meaningful detection happens. - Alerts that exist, but nobody owns them
An alert that no one reliably sees is indistinguishable from no alert.
A Note on SAQ A
PCI SSC has clarified that SAQ A includes eligibility criteria requiring the merchant to confirm their site is not susceptible to script attacks affecting their e-commerce system(s). Even when SAQ A changes a merchant’s validation route, script risk does not disappear, it just becomes a different evidence conversation with TPSPs and the merchant’s own site controls.
We hope that you find the above helpful – at Source Defense we consider it part of our mission to help the global QSA community better understand the nature of eSkimming attacks and the right way to assess whether a merchant is able to prevent them. We welcome your thoughts and engagement with us in this mission!
PCI DSS 4.0 makes client-side security a priority.
Source Defense delivers a solution for 6.4.3 and 11.6.1 without adding a burden to your security teams.