PCI DSS 6.4.3 and 11.6.1: Proving the Scripts on Your Payment Page Haven't Been Tampered With
Since 31 March 2025, PCI DSS requires every script on a payment page, and on the page that embeds one, to be inventoried, authorised and monitored for tampering. What 6.4.3 and 11.6.1 say, which pages are in scope, what changed for SAQ A, and the evidence assessors ask for.
Payment Security
Since 31 March 2025, two PCI DSS v4.x requirements have made every script that runs on a payment page, and on the page that embeds a payment form, something you must authorise, check and watch. Here is what Requirements 6.4.3 and 11.6.1 actually say, which pages they cover, what changed for SAQ A merchants, which controls meet them, and what your assessor will ask to see.
In short. 6.4.3 is about prevention: keep an inventory of every script on the payment page with a reason for each, authorise each one, and assure its integrity. 11.6.1 is about detection: alert when the scripts or the security-impacting HTTP headers the shopper's browser receives change without authorisation, at least weekly or at a frequency set by a targeted risk analysis. Embedding a provider's iframe does not take your page out of scope; the page around the iframe is in scope. Redirecting to a provider's hosted page largely does.
Why the payment page is the target
A modern checkout page runs a surprising amount of JavaScript: the payment form, analytics, tag managers, chat widgets, A/B testing, fraud tools, consent banners. Every one of those scripts runs with the same privileges in the shopper's browser. Any of them can read what the shopper types into the card fields and send it somewhere else.
That is e-skimming, also called Magecart or formjacking. The PCI Security Standards Council's March 2025 guidance describes two routes in. In a supply-chain attack, a third-party script the merchant trusts is compromised at its source, and the malicious version is served to every site that loads it. In a script injection attack, the attacker gets their own script onto the payment page, through a vulnerable plugin, a compromised admin account or a cross-site scripting flaw.
The guidance also distinguishes how the theft looks to the shopper. Silent skimming copies the card data in the background while the payment completes normally, so nobody notices, often for a long time. Double-entry skimming shows a fake form first, then an error, then the real form, and is usually spotted sooner because shoppers report entering their card twice. Neither shows up in server logs, because the theft happens in the browser and the stolen data never touches the merchant's servers.
What the two requirements say
Both were introduced in PCI DSS v4.0 in 2022 as future-dated requirements, best practice until 31 March 2025 and mandatory from that date.
Requirement 6.4.3 — manage payment page scripts
All payment page scripts that are loaded and executed in the consumer's browser are managed so that: a method is implemented to confirm that each script is authorised; a method is implemented to assure the integrity of each script; and an inventory of all scripts is maintained with written business or technical justification as to why each is necessary.
Requirement 11.6.1 — detect unauthorised changes
A change- and tamper-detection mechanism is deployed to alert personnel to unauthorised modification, including indicators of compromise, changes, additions and deletions, to the security-impacting HTTP headers and the script contents of payment pages as received by the consumer browser. It evaluates the received headers and payment pages at least weekly, or periodically at a frequency defined in the entity's targeted risk analysis under Requirement 12.3.1.
Three details in that wording do most of the work. "As received by the consumer browser" means checking the files on your server is not enough: a script can be clean on your origin and altered in transit, at a CDN or at the third party that serves it. "Security-impacting HTTP headers" means the Content Security Policy and similar headers are monitored too, because removing a CSP is one of the simplest ways to disable a defence. And 6.4.3 does not prescribe how authorisation happens: the guidance says it can occur before a script is added or changed, or as soon as possible afterwards, which matters for third-party scripts that change without warning.
Which pages are in scope, and who is responsible
How you take payments decides how much of this lands on you. The Council's guidance sets out the split of responsibility by integration type.
| How the payment page works | Merchant is responsible for | Payment provider is responsible for |
|---|---|---|
| Merchant-hosted form, merchant posts the data | Every script on the merchant's pages | Any scripts the provider supplies for its services |
| Merchant-hosted form, browser posts directly to the provider | Every script on the merchant's pages | Any scripts the provider supplies for its services |
| Provider's form embedded in an iframe | Every script on the page that contains the iframe | The scripts inside the iframe, which is the payment page itself |
| Redirect to the provider's hosted page | See the note below | Its hosted payment page |
| Fully outsourced, for example a pay-by-link | Nothing under 6.4.3 or 11.6.1 | Everything |
The iframe row is the one most merchants get wrong. Embedding a provider's payment form reduces scope, but the guidance is explicit that it does not remove the parent page from scope or make 6.4.3 and 11.6.1 inapplicable to it. A script on the parent page can overlay the iframe with a fake form, or redirect the frame, without ever touching the provider's code. Where scripts are used to create the iframe, the requirements apply to those scripts.
Two further points from the guidance change scope in practice:
- Single-page applications. In a multi-page checkout, only the page that embeds the payment form is normally in scope. In a single-page application the browser never fully reloads, so scripts loaded on any view stay in memory and can reach the payment form. The guidance treats the whole application as one page: every view is in scope.
- 3-D Secure scripts. Scripts run to perform 3-D Secure functions are not subject to 6.4.3, because of the trust relationship established with the 3DS provider. Anything else those scripts do outside the 3DS function is.
A note on redirects. The guidance's scoping section says the two requirements do not apply to merchant pages that redirect to a provider's page, including by HTTP redirect, meta refresh or JavaScript. Its section on redirection mechanisms says that where scripts are used as part of the redirection, the requirements apply to those scripts. If your redirect is driven by a script, treat that script as in scope until your acquirer or assessor tells you otherwise. It is the cheaper mistake to make.
What changed for SAQ A merchants
On 30 January 2025 the Council revised the Self-Assessment Questionnaire A, used by merchants who outsource all payment processing. It removed Requirements 6.4.3 and 11.6.1, and 12.3.1, from SAQ A, effective 31 March 2025, and replaced them with eligibility criteria. One of them requires the merchant to confirm that "their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s)".
That is not an exemption from the risk. The Council said the changes do not remove or diminish the underlying requirements, and the March guidance points SAQ A merchants to two ways of making the confirmation: get confirmation from the payment provider that its embedded form, implemented as instructed, includes techniques that protect the merchant's page from script attacks; or implement techniques like those in 6.4.3 and 11.6.1 on the merchant's page, directly or through a third party. In both cases you should be able to show how you reached the conclusion, because "we use an iframe" is not evidence that a script on your page cannot interfere with it.
SAQ A-EP, SAQ D for merchants and SAQ D for service providers still include 6.4.3 and 11.6.1, as does the Report on Compliance template. Which SAQ you may use is decided by your acquirer or the payment brands, not by you.
Controls that meet the requirements
PCI DSS does not mandate a mechanism. The Council's guidance describes four families of control, each with real limits, and most mature implementations combine two of them.
| Control | What it does well | Where it falls short |
|---|---|---|
| Content Security Policy | Browser-native. Limits where scripts can load from (script-src) and which iframes are allowed (frame-src); hashes or nonces can pin exactly which scripts may run; violation reports show blocked attempts. | Cannot build an inventory, keeps no baseline, cannot alert on its own removal or on header changes, and cannot see a permitted script whose behaviour changed unless it contacts a disallowed domain. Hard to maintain with hashes on a dynamic site. |
| Subresource Integrity | A hash in the script tag; the browser refuses to run the file if it does not match. Straightforward for scripts that rarely change. | Breaks when a third party legitimately updates a script, which is why many third-party scripts cannot use it. |
| Webpage monitoring | Watches the page as the browser renders it. Agent-based monitoring runs a script in real sessions; agentless monitoring walks the checkout with a headless browser on a schedule. Can catch form overlays and suspicious data flows. | Agents add another script to the page and can affect performance. Agentless checks can struggle with logins, CAPTCHAs and stateful flows, and only see what happens when they run. |
| Proxy-based | Runs at a reverse proxy or CDN edge, inspecting and controlling HTML and scripts before they reach the browser. Builds a complete script inventory with little application change. | Can be complex to configure, may add latency, and its effectiveness depends on detection logic that can generate false positives. |
A common, defensible combination is a strict CSP for prevention plus monitoring of what the browser actually receives for 11.6.1, with SRI on the first-party and static scripts where it is practical. Whatever you choose, the guidance is clear that if the mechanism only alerts rather than blocks, someone has to be ready to respond quickly.
Building the programme
Step 1 — Find out what actually runs
Load the payment page, and the page that embeds the form, in a real browser and record every script, including those loaded by other scripts and by the tag manager. Compare that list with what the team believes is there. The gap between the two is usually the first finding.
Step 2 — Justify or remove
Every script needs a written business or technical reason to be on the payment page. Analytics, heatmaps and marketing pixels rarely have one there. The simplest way to reduce scope is to stop loading scripts the checkout does not need, or move them into an isolated iframe.
Step 3 — Put authorisation into the release process
A ticket, a change record or a retained approval for each script and each change. For third-party scripts that change without notice, define how a change is detected and then authorised after the fact.
Step 4 — Assure integrity
CSP with an allowlist of sources at minimum, hashes or nonces where you can maintain them, SRI on static files. Keep the policy itself under change control, because the policy is a security-impacting header.
Step 5 — Detect, and decide who answers the alert
Deploy the 11.6.1 mechanism, set the frequency (weekly at minimum, or as your targeted risk analysis justifies), and route alerts to someone who knows what to do with them. Treat an unexplained new script on the checkout as a potential incident, not a ticket.
What your assessor will ask to see
The Council's guidance lists the evidence an assessed entity should be ready to provide. For 6.4.3 it comes down to five things, and for 11.6.1 the equivalent for the detection mechanism.
- Policies and procedures describing how payment page scripts are managed, kept up to date and in use.
- Defined roles and responsibilities for the activities, and people available to confirm they are followed.
- The script inventory with a technical or business justification for each script. A spreadsheet is acceptable in a simple environment; a tag or script management system in a complex one.
- Authorisation records, such as entries in a ticketing or workflow system, or retained email approvals.
- System configurations showing how each script is authorised and its integrity assured, such as the CSP, SRI attributes or the monitoring tool's configuration.
Where a penetration test fits
A penetration test does not make you compliant, and we are not a Qualified Security Assessor: compliance is validated by your QSA, or through the SAQ your acquirer specifies. What a test does is show whether the controls behind 6.4.3 and 11.6.1 would actually stop or catch an attacker, and produce findings your assessor can see you fixed. On a checkout we look at:
- The real script inventory against the declared one, including scripts pulled in by the tag manager and by other scripts.
- The CSP itself: wildcard sources,
unsafe-inline, permissiveframe-src, missing reporting, and whether it is present on every view of a single-page checkout. - Injection routes onto the page: cross-site scripting, especially DOM-based, on the checkout and parent pages, and weaknesses in the admin and content tooling that can change page templates.
- Iframe overlay and redirection: whether a script on the parent page can cover, replace or redirect the embedded payment form.
- Whether detection works: with your agreement and in a non-production environment, a benign, documented change to a script or header, to confirm the 11.6.1 mechanism raises an alert and someone responds to it.
Frequently Asked Questions
Click any question to expand the answer.
QWhen did 6.4.3 and 11.6.1 become mandatory?
On 31 March 2025. They were introduced in PCI DSS v4.0 in 2022 as future-dated requirements, best practice until that date. Fifty-one of the 64 new requirements in v4.x became effective on the same day.
QWe use our payment provider's iframe. Are we out of scope?
Not entirely. The provider is responsible for scripts inside the iframe, but the page that embeds it stays in scope, and 6.4.3 and 11.6.1 apply to the scripts on that page. A script on the parent page can overlay or redirect the payment form without touching the provider's code.
QWe are SAQ A. Do these requirements still affect us?
They were removed from SAQ A from 31 March 2025, but replaced by an eligibility criterion: you must confirm your site is not susceptible to attacks from scripts that could affect your e-commerce systems. The Council's guidance suggests getting that confirmation from your provider or implementing techniques like those in 6.4.3 and 11.6.1 yourself.
QHow often must the tamper-detection mechanism run?
At least weekly, or at a frequency defined in a targeted risk analysis under Requirement 12.3.1. The guidance notes that malicious changes can persist undetected between checks, so more frequent or real-time monitoring is recommended where feasible.
QIs a Content Security Policy enough on its own?
Usually not. CSP helps with authorisation and, to a degree, integrity, but it cannot build an inventory, keeps no baseline, cannot alert on its own removal or on header changes, and cannot see a permitted script whose behaviour changed. Most implementations pair it with monitoring for 11.6.1.
QOur checkout is a single-page application. What is in scope?
All of it. In a single-page application scripts loaded on any view stay in memory and can reach the embedded payment form, so the guidance treats every view of the application as in scope for 6.4.3 and 11.6.1.
QDoes 6.4.3 apply to 3-D Secure scripts?
Not to scripts run to perform 3-D Secure functions, because of the trust relationship established with the 3DS provider. Any script run outside the 3DS function is subject to 6.4.3.
QIs our analytics vendor a third-party service provider for PCI?
Not for Requirements 12.8 and 12.9, if its only service is providing scripts unrelated to payment processing that cannot affect the security of cardholder data. Its scripts on your payment page are still yours to manage under 6.4.3 and 11.6.1.
QWhat should we ask our payment provider for?
Its Attestation of Compliance, to confirm which of its services were covered by its assessment, and the written split of responsibilities under Requirement 12.9.2, including how each party addresses 6.4.3 and 11.6.1. Ask also whether its embedded form includes protections against attacks from scripts on your page, and how you implement it so they work.
QCan a penetration test make us compliant with 6.4.3 and 11.6.1?
No. Compliance is validated by your assessor or through the SAQ your acquirer specifies. A test shows whether your controls would stop or detect an attacker in practice, and gives you findings and evidence of remediation that support the assessment.
Related reading
Cross-site scripting is the most direct way onto a payment page; the defences are covered in our secure coding practices guide. For how a web application test is scoped and where the effort goes, see web application penetration testing in 2026. Third-party scripts are a software supply chain problem in the browser; our article on software bills of materials covers the server-side half of the same problem.
About Adayptus
Adayptus Consulting Private Limited is an application security testing firm based in Noida, India, working across web, mobile, API and cloud security testing since 2018. We are not a QSA; we test the payment journeys that QSAs assess, and we work alongside your assessor rather than in place of one.
What we can do for you:
- Checkout and payment page testing. Web application penetration testing that includes the client side of the payment journey: real script inventory, CSP review, injection routes onto the page, iframe overlay and redirection, and a detection test agreed with you. Every finding is reproduced by hand, and a remediation retest is included.
- The code behind it. Secure code review of checkout templates and the admin tooling that can change them, where a flaw would let an attacker add a script.
- For banks and payment businesses. Our BFSI security practice covers card and digital payment journeys end to end, including the APIs and mobile apps that sit beside the web checkout.
Sources
- PCI Security Standards Council, Information Supplement: Payment Page Security and Preventing E-Skimming – Guidance for PCI DSS Requirements 6.4.3 and 11.6.1, version 1.0, March 2025.
- PCI Security Standards Council, Important updates announced for merchants validating to Self-Assessment Questionnaire A, 30 January 2025.
- PCI Security Standards Council, Now is the time for organizations to adopt the future-dated requirements of PCI DSS v4.x, 20 August 2024.
Requirement wording is quoted from the Council's information supplement, which states that it does not replace or supersede the PCI DSS. Confirm requirements against the current version of the standard and your applicable SAQ or ROC template.
Adayptus Consulting
Application Security Testing, Adayptus
Adayptus Consulting Private Limited is an application security testing firm based in Noida, India, working across web, mobile, API and cloud security testing since 2018.
On This Page
- Why the payment page is the target
- What the two requirements say
- Which pages are in scope, and who is responsible
- What changed for SAQ A merchants
- Controls that meet the requirements
- Building the programme
- What your assessor will ask to see
- Where a penetration test fits
- Frequently Asked Questions
- Related reading
- About Adayptus
- Sources
