PCI DSS 6.4.3 and 11.6.1 Explained: Stopping Payment-Page Skimming

A skimmer does not break into your database. It edits a script on your payment page so the customer’s browser sends the card number to the attacker on the way to the processor. PCI DSS v4.0.1 added two requirements aimed exactly at this attack — one to control the scripts, one to catch them being changed.

Payment-page skimming (Magecart and its cousins) works because modern payment pages assemble themselves in the customer’s browser from scripts loaded from many sources — analytics, tag managers, chat widgets, ads. Each script can read the form fields. An attacker who injects or alters one script exfiltrates card data before it ever reaches your server. Traditional server-side controls do not see it; the tampering happens in the browser.

PCI DSS v4.0.1 responds with two paired requirements. 6.4.3 manages which scripts run on the payment page. 11.6.1 detects when those scripts are changed without authorization. Both were best practice until 31 March 2025 and are now required. This article explains what each demands and how an SMB implements both.

Requirement 6.4.3 — manage every script on the payment page

The requirement says all payment page scripts loaded and executed in the consumer’s browser must be managed three ways:

• **A method to confirm each script is authorized.** Every script — first-party and third-party — is explicitly approved before it runs. Approval can be a manual sign-off or an automated workflow; the standard accepts either.
• **A method to assure the integrity of each script.** The script cannot have been tampered with between your intent and the browser executing it.
• **An inventory of all scripts, with written business or technical justification for each.** A script with no justification is a script that should not be there. The inventory is the artifact the assessor reviews.

The Customized Approach Objective states the intent plainly: “Unauthorized code cannot be executed in the payment page as it rendered in the consumer’s browser.” The mechanism is up to you; the outcome is not.

How an SMB implements it:

1. Build the script inventory. List every script the payment page loads — first-party bundles, the tag manager, analytics, the chat widget, fraud scripts, the processor’s own scripts. For each, write one line on why it is necessary. This inventory is the foundation; without it, the other two parts cannot be done. 2. Authorize scripts via a workflow. A tag manager with an approval step, or a change-reviewed content pipeline, so a script cannot be added without a sign-off. The authorization can be confirmed after a change “as soon as possible” where pre-approval is impractical — the standard allows this, but the confirmation must happen. 3. Enforce integrity with SRI and CSP. Sub-resource Integrity (SRI) lets the browser validate that a script has not been tampered with by checking a hash. A Content Security Policy (CSP) limits the locations the browser can load scripts from and transmit account data to. Together they are the standard’s recommended integrity mechanism, and they are free. 4. Use the iframe exception where it applies. If you embed the processor’s payment form in an iframe, the scripts inside the iframe are the processor’s responsibility, not yours. The standard is explicit: the entity “should expect the TPSP/payment processor to provide evidence” it meets 6.4.3. Get that evidence in writing. Your scripts on the parent page are still in scope; the iframe’s are not.

Requirement 11.6.1 — detect tampering on the payment page

Where 6.4.3 prevents unauthorized scripts, 11.6.1 detects them anyway — defense in depth. The requirement says a change- and tamper-detection mechanism is deployed to:

• **alert personnel to unauthorized modification** of the security-impacting HTTP headers and the script contents of payment pages **as received by the consumer browser**,
• **evaluate the received HTTP headers and payment pages** (not just the server-side source), and
• **run at least weekly, or at a frequency defined by a targeted risk analysis** performed per requirement 12.3.1.

The key phrase is “as received by the consumer browser.” Server-side change detection misses client-side injection; the mechanism must look at what the browser actually gets. The Customized Approach Objective: “E-commerce skimming code or techniques cannot be added to payment pages as received by the consumer browser without a timely alert being generated. Anti-skimming measures cannot be removed from payment pages without a prompt alert.”

How an SMB implements it:

1. CSP violation reporting. Configure the CSP report-to or report-uri directive so violations (a script trying to load from a non-approved origin) are sent to a collector you monitor. CSP violations are a free, built-in tamper signal. 2. Watch the CSP itself. A change to the CSP is itself tampering — an attacker who loosens the policy before injecting. Alert on CSP changes. 3. Synthetic user monitoring. An external service that periodically requests the payment page from the internet and compares the received scripts and headers to a known-good baseline. This is the “as received by the browser” check, and it is typically a subscription an SMB can afford. 4. Tamper-detection script. A tamper-resistant script embedded in the payment page that alerts (and can block) when it detects malicious script behavior. Often bundled with the synthetic-monitoring vendor. 5. Set the frequency. Weekly at minimum, or document a targeted risk analysis justifying a different cadence. The TRA is a requirement 12.3.1 artifact — see the TRA template article.

How the two requirements fit together

6.4.3 and 11.6.1 are a pair: 6.4.3 shrinks the script surface and locks the approved scripts’ integrity; 11.6.1 watches the result so that if a script is added or altered anyway, someone is alerted within a week. Doing one without the other leaves a gap — authorized scripts without tamper detection miss a compromised vendor CDN; tamper detection without script management drowns in alerts from scripts nobody authorized.

The shared mechanism is the CSP: it enforces authorization (only approved origins) and produces violation reports (tamper detection). A well-built CSP does much of both requirements at once.

The scope-reduction interaction

If you outsource the payment page to a processor-hosted form or a P2PE terminal, these requirements largely move to the processor — the standard’s applicability notes confirm the TPSP is responsible for scripts inside its embedded iframe. This is the same lever as scope reduction: the cheapest way to meet 6.4.3 and 11.6.1 is to not have a payment page of your own. Where you must run one, the inventory-plus-CSP-plus-monitoring path above is the implementation.

How this fits the series

This is the deep-dive companion to the PCI DSS pillar, paired with the scope reduction piece — both reduce the payment attack surface. It feeds the SAQ guide (these requirements appear on the e-commerce SAQs) and the TRA template (11.6.1’s frequency needs a TRA).

What to do next

Build the script inventory for your payment page this week — it is the one artifact both requirements depend on, and it is free. Then add a CSP with report-to, confirm SRI on your first-party scripts, and stand up either synthetic monitoring or a tamper-detection script. The inventory plus the CSP is most of the way to compliance; the monitoring closes the detection half.

Want a skimming-control review before your assessment? Book a 30-min **PCI scope reduction + readiness review** — we audit your payment-page scripts against 6.4.3, check your CSP and monitoring against 11.6.1, and hand you the gap list. Bilingual EN/FR, no obligation.

→ /pci-dss-assessment/