PCI DSS 4.0.1 requirements 6.4.3 and 11.6.1 govern the scripts and HTTP headers on your payment pages. 6.4.3 makes you inventory, authorize, and assure the integrity of every script. 11.6.1 makes you detect and alert on unauthorized changes to that page's scripts and security headers. Both have been mandatory since 2025-03-31. This guide breaks down each clause, what it means for the page in production, and the specific evidence a QSA expects it to produce.
These two requirements exist because of e-skimming. Magecart-style attackers do not breach your server. They alter a script the browser loads, then capture cardholder data straight from the form as the user types it. A processor iframe does not cover the page that frames it. cside lives in that exact gap: it records every script real browsers execute on the payment page, captures authorization, and flags integrity and header changes as they happen.
What requirement 6.4.3 actually requires
6.4.3 sets three obligations for every payment-page script. Read each as a separate clause, because a QSA will:
- A method confirms each script is authorized before it loads or executes.
- A method assures the integrity of each script.
- An inventory of scripts is maintained with a written justification for why each is necessary.
"Authorized" and "necessary" are the two words that trip teams up. Authorization is a recorded decision: a named approver signed off that this script may run on a page in cardholder-data scope. Justification is the business reason it exists. A tracking pixel marketing added last quarter usually has neither, which is exactly the kind of finding 6.4.3 surfaces.
Scope is wider than first-party code. The control covers every script the browser executes on the page: your own bundles, third-party SDKs, and the fourth-party scripts those vendors pull in at runtime. A tag manager that injects three more scripts after page load is three more entries in your inventory, and those entries change without a deploy on your side.
The PCI SSC lists Subresource Integrity (SRI) hashes and Content-Security-Policy as example integrity mechanisms. They hold for static assets. They break the moment a script is dynamic. An analytics tag or A/B tool that updates legitimately invalidates the hash, so a pinned SRI either blocks a good update or gets removed and stops protecting anything. Content Security Policy has the same limit: it cannot vouch for what an allowed script does at runtime. That is why integrity for real payment pages has to be assessed on what executed, not on a hash set at build time.
What requirement 11.6.1 actually requires
11.6.1 is a detection control, not a management one. It requires a change-and-tamper-detection mechanism that does two things:
- Alerts personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) of the HTTP headers and the content of payment pages as received by the consumer browser.
- Evaluates the received headers and page content at a frequency set by your targeted risk analysis under requirement 12.3.1, or at least once every seven days.
The phrase "as received by the consumer browser" carries the requirement. 11.6.1 is not asking what your CDN served or what your repo contains. It asks what the browser rendered, after every redirect, injection, and runtime modification. A skimmer reads navigator.webdriver, missing automation properties, and the absence of real interaction to recognize a scanner, then serves clean code to it and the payload to a human. A control that only sees the scanned version never fires.
HTTP headers are in scope because they are an attack surface, not a config detail. A weakened or stripped Content-Security-Policy header lets a malicious script load that the policy was meant to block. 11.6.1 wants you to notice the header changed at all, and to notice on the delivered response, not in your origin config.
How the two requirements split the work
6.4.3 governs what you allow; 11.6.1 governs what happened on the page.
| Question | Requirement | What it governs | Failure mode it catches |
|---|---|---|---|
| Which scripts are allowed here, and why? | 6.4.3 | Authorization, justification, integrity, inventory | An unapproved or undocumented script in scope |
| Did the page or its headers change without approval? | 11.6.1 | Detection and alerting on script and header changes | A live tamper the inventory never noticed |
| How often do we check the delivered page? | 11.6.1 + 12.3.1 | Frequency, with a seven-day floor | Stale checks that miss transient changes |
Treat them as one loop, not two projects. An inventory with no live detection is a list that goes stale the moment a vendor pushes an update. Detection with no inventory produces alerts nobody can triage, because there is no baseline of what "authorized" looks like.
The evidence each control has to produce
A QSA assesses compliance from artifacts. Map each clause to the record it generates so you can hand over the exact thing they ask for.
| Clause | Evidence artifact | What it has to show |
|---|---|---|
| 6.4.3 inventory | Script inventory tied to in-scope pages | Every script's URL, owner, and last-seen version |
| 6.4.3 authorization | Approval record per script | Who approved it, when, and the data it touches |
| 6.4.3 justification | Business-reason note per script | Why the script is necessary on a payment page |
| 6.4.3 integrity | Integrity history | How each script is confirmed unaltered over time |
| 11.6.1 detection | Change log with alerts | Timestamp, diff, page, and who was notified |
| 11.6.1 header evaluation | Header history per page | Security-header values and changes between loads |
| 11.6.1 frequency | Risk analysis + check cadence | The 12.3.1 justification and proof checks ran |
The artifact teams most often lack is integrity history and header history over time. A single snapshot proves the page was clean once. A QSA assessing 11.6.1 wants evidence you would have caught a change: a timestamped record across many real page loads, not one screenshot.
Why a processor does not close this for you
A common assumption is that hosting payment fields in a Stripe, Adyen, or Braintree iframe pushes 6.4.3 and 11.6.1 onto the processor. It does not. The iframe is sandboxed, but the merchant page that frames it is not. Your analytics, A/B tooling, session-replay, and chat widgets all run in the same top-level browser context, and a script there can read the DOM, overlay a fake input field on top of the iframe, or redirect the form on submit. The January 2025 SAQ A update narrowed eligibility because so few real payment pages are free of third-party scripts, and it added a criterion that you confirm your site is not susceptible to script-based attacks, which is hard to prove without monitoring. The requirements stay with the page you serve.
Why the threat keeps getting harder to scan for
The reason 11.6.1 insists on the delivered page is that attacker tooling is built to defeat anything that isn't real. Headless and instrumented browsers leak: a navigator.webdriver flag, missing chrome runtime objects, Chrome DevTools Protocol Runtime artifacts, and impossible timing all mark a session as non-human. Skimmers fingerprint those signals and stay dormant for crawlers and synthetic checks.
Evasion tooling has moved the other way too. cside's research report on the future of web security found that playwright-stealth, automation tuned to suppress those leaks, was roughly ten times more widely used by the end of 2025. The practical takeaway for 6.4.3 and 11.6.1: integrity and change detection have to run where the cardholder data is actually entered, in the real browser session, not from an external vantage point an evasive script can identify and hide from.
How cside produces this evidence at the browser layer
cside instruments the payment page in real browsers, which is the surface both requirements point at.
- For 6.4.3, it captures the full script inventory, including the fourth-party scripts vendors pull in at runtime, records authorization and justification beside each entry, and keeps an integrity history so you can prove a script stayed intact between versions.
- For 11.6.1, it monitors script content and HTTP security headers on the delivered page, diffs them across loads, and alerts on unauthorized change, with a timestamped record that answers the 12.3.1 frequency question without a manual weekly pull.
- It also surfaces the runtime payload of each script and pairs script behavior with device, real-IP, and VPN/proxy signals, so a flagged change comes with context instead of a bare hash mismatch.
Because it watches what executed rather than what a scanner was shown, cside captures the same browser evidence an e-skimming attacker tries to hide. That aligns the compliance workflow with the real threat. For the operational rollout and the QSA-reporting view, the guides below go deeper.
Further reading on cside
- How to comply with PCI 6.4.3 and 11.6.1
- What QSAs look for when assessing 6.4.3 and 11.6.1
- Solution comparison for PCI DSS 6.4.3 and 11.6.1
- What is client-side security
- cside PCI Shield
- The fastest way to comply with PCI DSS 6.4.3 & 11.6.1
- PCI SSF vs PCI DSS: which standard applies to you
As of 2026-06-18, treat this as operational guidance, not legal advice. Confirm the exact control language with your QSA, counsel, or risk owner.
