November 4, 2026
Updated: November 4, 2026
Authorize, inventory and monitor every payment page script, then prove the controls work against skimming.
Mohammed Khalil
PCI DSS 6.4.3 and 11.6.1 are the PCI DSS v4.0.1 requirements that protect e-commerce payment pages from skimming scripts, mandatory since 31 March 2025. Requirement 6.4.3 requires every payment page script to be authorized, integrity-checked and inventoried with a written justification. Requirement 11.6.1 requires a change- and tamper-detection mechanism that alerts your team to unauthorized changes in the security-impacting HTTP headers and script contents of payment pages, run at least weekly or at a frequency set by a targeted risk analysis.
| Requirement 6.4.3 | Requirement 11.6.1 | |
|---|---|---|
| Goal | Prevent unauthorized or altered scripts from running on the payment page | Detect and alert on unauthorized changes that slip through |
| What it covers | All payment page scripts loaded and executed in the consumer's browser | Security-impacting HTTP headers and the script contents of payment pages, as received by the consumer's browser |
| Core elements | Authorization, integrity, inventory with written business or technical justification | Change- and tamper-detection mechanism, alerting personnel, evaluation of received headers and pages |
| Frequency | Ongoing; authorize before a change or as soon as possible after it | At least weekly, or as defined in a targeted risk analysis under Requirement 12.3.1 |
| Customized approach objective | "Unauthorized code cannot be executed on the payment page as it is rendered in the consumer's browser." | Skimming code cannot be added, and anti-skimming measures cannot be removed, without a timely alert |
| Typical evidence | Script inventory, authorization records, integrity configurations, procedures, interviews | Mechanism settings, list of monitored pages, monitoring results, alert records, a TRA if used, incident response plan |
| PCI DSS reference | Section 6.4 (public-facing web applications) | Section 11.6 (unauthorized changes on payment pages) |
The two requirements are designed as a pair. Requirement 6.4.3 is the preventive control that decides which code may run. Requirement 11.6.1 is the detective control that tells you when reality no longer matches that decision.
Modern checkout pages run code from many places: your own servers, analytics and marketing vendors, tag managers, fraud tools, chat widgets and the scripts those vendors load in turn. The PCI Security Standards Council (PCI SSC) notes in its March 2025 information supplement that every one of those scripts can read, alter or delete page content, which means any of them could also read card data as a customer types it.
The Council's guidance describes two common attack routes. In a supply-chain attack, an attacker compromises a third-party script, and every site that loads it starts sending card data elsewhere. In a script injection attack, the attacker gets malicious code into the merchant's own page, often through a compromised content management system, a weak admin account or a cross-site scripting flaw. The industry calls both Magecart or formjacking.
The same supplement distinguishes two outcomes. Silent skimming copies data in the background while the payment still succeeds, so neither the customer nor the merchant notices. Double-entry skimming shows a fake form first, then an error, then the real form; it is noisier and usually found sooner.
The British Airways breach is a well-documented example of silent skimming. According to the UK Information Commissioner's Office penalty notice of October 2020, an attacker who had already reached BA's network edited a JavaScript file on britishairways.com so that payment card data was copied to an attacker-controlled domain. The modified code ran for 15 days in 2018 without interrupting bookings, and BA learned of it from a third party. The ICO estimated that personal data of about 429,612 customers and staff was potentially accessed and fined BA £20 million. The case predates PCI DSS v4, but it shows exactly the gap that 6.4.3 and 11.6.1 close: nobody was checking what the payment page actually delivered to browsers.
E-skimming is a client-side form of the wider supply chain attack problem. Your server can be fully patched while a script from a vendor's vendor is quietly reading every keystroke.
The defined approach in PCI DSS v4.0.1 states that all payment page scripts that are loaded and executed in the consumer's browser are managed as follows:
PCI DSS defines a payment page script as any programming language commands or instructions on a payment page that the consumer's browser processes or interprets, including those that interact with the page's document object model (DOM). JavaScript is the obvious example; the Council's supplement also mentions WebAssembly. HTML markup and CSS style rules are not programming languages, so they are not scripts for this requirement.
Each script needs an approval decision. The standard does not say who approves, how, or whether the process is manual or automated. The guidance for 6.4.3 recognizes that third-party scripts can change without warning, so authorization can happen before a script is added or changed, or as soon as possible after a change is detected. What matters is that you can show a record of who approved which script and when.
You must have a method that assures each script has not been tampered with. PCI DSS does not mandate a specific mechanism. The guidance gives Content Security Policy (CSP) and Subresource Integrity (SRI) as examples, and the Council's supplement adds webpage monitoring, proxy-based controls, file hashing, behavior monitoring, static analysis and tamper-resistant scripts. Integrity checks matter at two moments: when a script is introduced and whenever it is updated.
You must keep a list of every script on the payment page with a written business or technical reason for it. The Council says a spreadsheet can be enough in a simple environment, while complex sites may need automated tools or workflow systems. Removing scripts that cannot be justified is the cheapest security control on this page: every script you delete is one you never have to authorize, hash or monitor.
The Council's supplement states that validation to 6.4.3 is not required for 3-D Secure (3DS) scripts, because of the trust relationship between the 3DS provider and the merchant established through due diligence and the business agreement. Any script that runs for another purpose remains in scope.
Requirement 6.4.3 also connects to Requirements 6.1.1 and 6.1.2. Your policies and procedures must describe how you manage payment page scripts, and roles and responsibilities for that work must be documented, assigned and understood.
The defined approach for 11.6.1 states that a change- and tamper-detection mechanism is deployed as follows:
PCI DSS v4.0.1, published on 11 June 2024, narrowed the original v4.0 wording from "the HTTP headers and the contents of payment pages" to "the security-impacting HTTP headers and the script contents of payment pages." That clarification keeps the focus on changes that can actually affect card data.
The Council's supplement lists examples, while noting that the right set depends on your architecture and supported browsers:
The supplement points to the OWASP Secure Headers Project for header behavior. A weakened or deleted CSP is as important to detect as a new script, because removing the policy can silently re-open the page to injected code.
This phrase is the heart of 11.6.1. Comparing files in your repository or on your web server is not enough, because skimming code is often added at a CDN, by a third-party host, through a tag manager or inside a script that loads another script at runtime. The mechanism has to evaluate what a browser actually receives. The Council describes three kinds of change it should catch: a header or script that newly appears, one that is changed, and one that is deleted.
The weekly minimum is a compliance baseline. The Council's own guidance warns that malicious modifications could persist undetected between checks, so it recommends frequent or even real-time monitoring where feasible. A skimmer that runs for six days between weekly checks can still collect a lot of cards. If you choose a different frequency, Requirement 12.3.1 requires a documented targeted risk analysis to justify it.
An alert that lands in an unread mailbox does not meet the intent. Requirement 11.1.2 requires roles and responsibilities for 11.6.1 activities, and Requirement 12.10.5 requires the incident response plan to include monitoring and responding to alerts from the change- and tamper-detection mechanism for payment pages. Assessors may ask to observe the process, or a tabletop exercise if no real incident has occurred.
The requirements apply differently depending on how your checkout is built. The table below summarizes Table 3 of the Council's March 2025 information supplement.
| Payment page scenario | Merchant is responsible for | Payment provider (TPSP) is responsible for |
|---|---|---|
| Merchant-hosted form, merchant posts data to the processor | Any scripts on the merchant's webpages | Any scripts the provider includes for its services |
| Merchant-hosted form, direct post to the processor | Any scripts on the merchant's webpages | Any scripts the provider includes for its services |
| Embedded payment form (iframe) | Any scripts on the merchant page that includes the iframe (the parent page) | Scripts inside the provider's iframe (the payment page) |
| Redirect to the provider's hosted page | Any scripts on the merchant page that includes the redirection mechanism | Any scripts the provider includes for its services |
| Fully outsourced, such as a "link to pay" | Nothing related to 6.4.3 and 11.6.1 | Any scripts the provider includes for its services |
Three details cause most scoping mistakes.
An iframe does not take the parent page out of scope. PCI DSS v4.0.1 added Applicability Notes stating that 6.4.3 and 11.6.1 also apply to a merchant webpage that embeds a provider's payment page or form, while scripts inside the provider's iframe are the provider's responsibility. A malicious script on the parent page can overlay or replace the iframe, so the parent page matters.
Redirects reduce, but do not always remove, script exposure. The Council's scoping section says 6.4.3 and 11.6.1 do not apply to merchants whose pages redirect to a provider's page by HTTP 30x, meta refresh or JavaScript. The same supplement also says that where scripts are used as part of a redirection mechanism, the requirements apply to those scripts. Ask your assessor or acquirer how they read your specific redirect.
Single-page applications widen scope. In a multi-page checkout, the browser reloads at each step and old scripts are cleared, so typically only the page embedding the payment form is in scope. In a single-page application (SPA), scripts loaded earlier in the session stay in memory. The Council says 6.4.3 and 11.6.1 then apply to all views in the application that could affect the embedded payment form.
Self-Assessment Questionnaire (SAQ) A is the shortest PCI DSS questionnaire, for card-not-present merchants that fully outsource account data functions to compliant providers. Many e-commerce merchants that use a hosted or embedded payment form validate with it, so its 2025 changes affect a large share of online stores.
On 30 January 2025, the PCI SSC announced revisions to SAQ A:
SAQ A r1 keeps the other e-commerce criterion as well: all elements of the payment pages or forms delivered to the customer's browser must originate only and directly from a PCI DSS compliant third-party service provider or payment processor. It also notes that requirements protecting computer systems still apply to the merchant webpage that holds the redirection mechanism or the embedded form, because those pages affect how account data is transmitted.
The Council was explicit that the change affects how merchants report, not what PCI DSS requires: the underlying requirements remain in the standard and are still assessed in full in SAQ A-EP, SAQ D for merchants, SAQ D for service providers and the Report on Compliance.
On 28 February 2025, the Council published FAQ 1588 to explain the criterion. It applies only to e-commerce merchants with a webpage that includes a provider's embedded payment page or form, such as an iframe. It does not apply to merchants that redirect to the provider or fully outsource payment, for example with an emailed payment link.
FAQ 1588 gives two routes to confirm that the merchant's webpage is not susceptible to script attacks:
The FAQ adds that a provider of third-party scripts is not considered a third-party service provider for SAQ A purposes if it only provides scripts unrelated to payment processing that cannot affect the security of cardholder data. FAQ 1592 applies the same test to Requirements 12.8 and 12.9.
| Your checkout | Script-related obligation (typical) | What to keep on file |
|---|---|---|
| Redirect to a provider-hosted page | 6.4.3 and 11.6.1 not in SAQ A; the script eligibility criterion does not apply | Provider AOC; evidence the redirect page is controlled |
| Embedded iframe, SAQ A | Confirm the eligibility criterion by route 1 or route 2 of FAQ 1588 | Either your own 6.4.3/11.6.1-style evidence, or the provider's written confirmation, its AOC and proof you followed its implementation instructions |
| Merchant-hosted form or direct post (SAQ A-EP or SAQ D) | Full 6.4.3 and 11.6.1 | Full evidence set described later in this guide |
| Larger merchants and service providers (SAQ D or ROC) | Full 6.4.3 and 11.6.1 | Full evidence set |
Two cautions apply. First, the provider confirmation in route 2 covers how the provider's solution protects your page when implemented as instructed; it cannot cover a marketing tag your team added to the parent page next to the iframe. The Council's supplement itself notes that providers cannot fully address skimming risk on a merchant's website because they do not control it. Second, on 4 August 2026 the Council revised FAQ 1331 to stress that SAQ eligibility criteria should not be used as a guide to requirement applicability in a Report on Compliance unless agreed with the compliance-accepting entity. Your acquirer or the payment brands, not a blog post, decide which SAQ you may use.
For a wider view of where SAQs and assessments fit, see our guide to PCI DSS penetration testing, which covers Requirement 11.4 testing alongside these script controls.
An inventory built from your source code alone will be incomplete. Build it from what browsers actually load, then reconcile it with what your teams believe they deployed.
A practical inventory record looks like this:
| Field | Example entry (illustrative) |
|---|---|
| Script source | https://cdn.example-analytics.com/v3/tag.js |
| Pages where it loads | /checkout, /checkout/payment (SPA views) |
| Loaded by | Tag manager container GTM-XXXX (fourth-party: no) |
| Owner | Marketing operations |
| Business or technical justification | Conversion measurement required for paid campaigns |
| Access to payment fields needed? | No |
| Integrity method | Version pinned; SRI hash; CSP allowlist entry |
| Authorized by and date | Security lead, ticket SEC-1042, 2026-10-12 |
| Monitoring coverage | Included in weekly and real-time change detection |
| Next review trigger | Vendor version change or quarterly review |
The Council's assessment guidance lists acceptable authorization records such as entries in a workflow, service management or ticketing system, or retained email approval. Inventory records can live in a spreadsheet, document, database, CMS page or tag management system.
If you build software continuously, the supplement suggests adding script inventory checks to your CI/CD pipeline so that only approved scripts reach production. That makes authorization part of the release rather than a quarterly clean-up.
No single control meets every element of both requirements. The Council's supplement maps several controls to the elements, and most mature programs combine at least two.
A Content Security Policy tells the browser which sources may load scripts (script-src) and frames (frame-src). Nonces or hashes can restrict execution to specific approved scripts, and reporting directives (report-to, or the older report-uri) send violation events to an endpoint you control. A simplified example for a checkout page:
Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-r4nd0m' https://js.payments.example; frame-src https://pay.payments.example; object-src 'none'; base-uri 'self'; report-to csp-endpointCSP is browser-native and helps with authorization, inventory and partial detection. The Council lists its limits: CSP cannot build a list of unauthorized scripts by itself, does not keep a baseline across sessions, cannot detect the deletion of a security header, and cannot tell when an allowed script changes its behavior unless that script contacts a disallowed domain. If a trusted third-party script is compromised, CSP still lets it run.
Subresource Integrity adds a cryptographic hash to a script tag. If the file the browser receives does not match, the browser blocks it.
<script src="https://cdn.example.com/lib/v2.4.1/widget.js"
integrity="sha384-BASE64HASHVALUE"
crossorigin="anonymous"></script>SRI works well for versioned static files. It is impractical for scripts that change often or are generated per session, it fails silently with no native alert, and it does not support reporting. On its own, it cannot satisfy 11.6.1's alerting element.
Monitoring examines the payment page as it is rendered in a browser or a synthetic browser and watches what scripts do. Agent-based monitoring injects a script that tracks DOM changes, network requests and behavior in real user sessions. Agentless monitoring uses a headless browser that walks through checkout on a schedule. Agent-based tools see what real users get but must be integrated carefully; agentless tools add nothing to user sessions but can struggle with logins, CAPTCHAs and stateful flows, and only see what is served to their test sessions.
A reverse proxy or CDN edge can inspect and rewrite HTML and scripts before they reach the browser, inventory every script load, enforce CSP and block unapproved content. These controls need little application change but can add latency and false positives if tuned poorly.
| Control | Helps meet | Blind spots | Evidence it produces |
|---|---|---|---|
| CSP with nonces or hashes | 6.4.3 authorization and integrity (partial); 11.6.1 alerting through violation reports | Compromised allowlisted scripts; deleted headers; behavior changes | Header configuration, violation report logs |
| SRI | 6.4.3 integrity for static scripts | Dynamic scripts; no alerting; silent failure | Script tags with integrity values, build records |
| Agent-based monitoring | 6.4.3 inventory and integrity; 11.6.1 headers, script changes and indicators of compromise | Integration errors; performance impact if misconfigured | Dashboards, change history, alert logs |
| Agentless (synthetic) monitoring | 11.6.1 headers and script changes on a schedule | Content served only to real users; login and CAPTCHA flows | Scan schedules, diff reports, alerts |
| Proxy or CDN edge | Inventory, enforcement, header and script change detection | Latency and tuning; traffic that bypasses the proxy | Policy configuration, block and alert logs |
| Manual review and sign-off | Inventory and authorization | Speed and scale | Tickets, approvals, review records |
A secondary analysis published by the Cloud Security Alliance in July 2026 highlights why this layering matters: attackers can serve malicious scripts selectively, only to real users or only in some regions or time windows, so periodic crawls can miss them. That is a strong argument for combining scheduled checks with monitoring of real sessions, even though the standard itself sets a weekly minimum.
Compliance tools tell you a control exists. Testing tells you whether it works when someone tries to get unauthorized code onto your payment page. A focused assessment of payment page script controls usually covers the following, inside written rules of engagement and preferably against a staging copy that mirrors production headers and third-party integrations.
| Test | What the tester does | What a pass looks like | Requirement |
|---|---|---|---|
| Inventory reconciliation | Captures every script loaded on in-scope pages across sessions, devices and regions, then compares the list with your inventory | No unlisted scripts; every listed script has an owner and justification | 6.4.3 |
| CSP review | Reviews the delivered policy: unsafe-inline, unsafe-eval, wildcard or broad CDN sources, missing frame-src, report-only mode, policy set by meta tag only, gaps between pages | Enforced policy that only allows approved sources, with reporting wired to a monitored endpoint | 6.4.3 integrity and authorization |
| SRI coverage | Checks which static first- and third-party scripts lack integrity attributes and whether hashes match pinned versions | Static scripts pinned and hashed, or another integrity method documented | 6.4.3 integrity |
| Benign tamper simulation | In staging, adds a harmless script not in the inventory (for example, one that writes a fixed string to the console), changes one byte in an approved script, removes the CSP header and adds a second CSP | Each change produces an alert to the named owner within the expected time | 11.6.1 |
| Alert-to-response drill | Follows each alert through triage and escalation against the incident response plan | Documented response, with the right people engaged | 12.10.5, 11.1.2 |
| Script write-path testing | Looks for ways an attacker could get code onto the page: stored cross-site scripting, CMS or tag manager accounts with weak access control, writable storage buckets or CDN origins that serve scripts, insecure deployment paths | No path lets an unauthorized user add or alter payment page code | 6.4.3 intent; Requirement 6 web application security |
| Iframe and SPA checks | Verifies that the parent page cannot be used to overlay or replace the provider's iframe, that frame-src restricts frame origins, and that scripts loaded in earlier SPA views are covered | Payment iframe origin enforced; SPA views included in monitoring | 6.4.3 and 11.6.1 scope |
Two points keep this testing safe and useful. First, tamper simulations use benign canary changes in an agreed environment; they never collect real card data and never touch live customer sessions without explicit written approval. Second, the output should be evidence your assessor can use: what was tested, when, which alerts fired, how long they took and what was fixed.
Write-path testing is where a web application penetration test adds the most value. Monitoring tells you after a skimmer appears; finding the stored XSS, over-privileged CMS role or exposed tag manager account that would let someone plant it prevents the incident. If your store runs on a hosted platform, the same thinking applies to themes, apps and checkout extensions; our Shopify penetration testing guide explains what is and is not in the merchant's control there.
The Council's supplement lists the evidence an entity should have ready. Organized by requirement:
| Requirement and testing procedure | Evidence to prepare |
|---|---|
| 6.1.1 policies for 6.4.3 | Documented policies and procedures for managing payment page scripts, kept up to date; staff who can confirm they are in use |
| 6.1.2 roles for 6.4.3 | Documented and assigned roles; staff who understand them |
| 6.4.3.a | Procedures covering authorization, integrity and inventory with justification |
| 6.4.3.b | Script inventory records with justifications; system configurations showing how each script is authorized and how integrity is assured; interviews confirming the process is followed |
| 11.1.2 roles for 11.6.1 | Documented and assigned roles for change and tamper detection |
| 11.6.1.a | Mechanism settings, the list of monitored payment pages, and monitoring results such as logs or reports |
| 11.6.1.b | Configuration showing the mechanism detects and alerts on unauthorized changes to security-impacting headers and script contents, and evaluates received headers and pages |
| 11.6.1.c | The documented targeted risk analysis, if you chose a frequency other than weekly |
| 11.6.1.d and e | Interviews and configuration settings showing the mechanism runs at least weekly or at the TRA frequency |
| 12.10.5 | An incident response plan covering alerts from the payment page mechanism, and the chance to observe the process or a tabletop exercise |
The Council gives examples of acceptable alert channels, including email, SMS, syslog events, Windows security log events and vendor logs. It also notes that the 6.4.3 script inventory can be used to configure the 11.6.1 mechanism, which is a good reason to keep one source of truth.
script-src that permits an entire public CDN lets attackers host code on that same CDN.If your checkout runs on cloud infrastructure, our guide to PCI compliance in the cloud covers shared-responsibility questions for the systems behind the payment page. For script vendors and payment providers, fold these checks into your third-party risk management reviews.
script-src and frame-src, and route violation reports to a monitored endpoint.A penetration test does not replace the 11.6.1 mechanism; that has to be a deployed, continuously running control. It also does not make you compliant on its own. Your assessor and compliance-accepting entity make that determination. What testing does is answer two questions monitoring cannot: can an attacker get unauthorized code onto your payment page, and do your controls actually alert when the page changes?
DeepStrike's penetration testing for compliance work follows that model. Our web application testing combines automation with in-depth manual testing, reports only vulnerabilities validated through exploitation in agreed scope, and delivers reports prepared to support compliance programs, including PCI DSS, with fix recommendations, remediation retesting and an attestation letter. For payment pages, that means testing the write paths and the CSP, SRI and change-detection controls described above, and giving your assessor evidence rather than assumptions.
Requirement 11.6.1 requires a change- and tamper-detection mechanism that alerts personnel to unauthorized changes, additions, deletions and indicators of compromise in the security-impacting HTTP headers and script contents of payment pages, as received by the consumer's browser. It must run at least weekly or at a frequency defined by a targeted risk analysis under Requirement 12.3.1.
Requirement 6.4.3 requires that every script loaded and executed on a payment page in the consumer's browser is authorized, has a method that assures its integrity, and appears in an inventory with a written business or technical justification.
Both were introduced in PCI DSS v4.0 in March 2022 as best practices and became mandatory after 31 March 2025. PCI DSS v4.0.1, published in June 2024, clarified their wording and applicability but did not change that date.
They are no longer listed in SAQ A as revised in January 2025. Instead, e-commerce merchants that embed a provider's payment form must confirm their site is not susceptible to script attacks, either by using techniques such as those in 6.4.3 and 11.6.1 or by obtaining confirmation from their PCI DSS compliant provider, as FAQ 1588 explains. Merchants that redirect to the provider or fully outsource payment are not subject to that criterion.
Usually not on its own. CSP helps with script authorization and partial integrity, but the Council notes it cannot alert on deleted headers, keep a baseline, or detect behavior changes inside an allowed script. Most entities pair CSP with SRI, monitoring or proxy-based controls and documented processes.
No. The standard requires the mechanism to run at least weekly, or at a frequency justified by a targeted risk analysis. The Council's guidance recommends frequent or real-time monitoring where feasible because a skimmer can operate undetected between weekly checks.
Not entirely. Scripts inside the provider's iframe are the provider's responsibility, but scripts on your page that embeds the iframe remain yours under PCI DSS v4.0.1. For SAQ A merchants, the same parent page is what the script eligibility criterion is about.
Yes. The PCI SSC ran a request for comments on v4.0.1 from 3 June to 20 July 2026 to plan the next iteration of the standard. That process does not change current requirements; v4.0.1, including 6.4.3 and 11.6.1, remains the version assessed.
Requirements 6.4.3 and 11.6.1 ask a simple question with a hard answer: do you know, and can you prove, what code your customers' browsers run on your payment page? Start by mapping in-scope pages and building the inventory from real browser sessions, then layer CSP, SRI and change detection, and rehearse the alert path. When you want independent proof that the controls hold, talk to DeepStrike about web application penetration testing focused on your checkout and payment page scripts.
Mohammed Khalil is a Cybersecurity Architect at DeepStrike, specializing in advanced penetration testing and offensive security operations. With certifications including CISSP, OSCP, and OSWE, he has led numerous red team engagements for Fortune 500 companies, focusing on cloud security, application vulnerabilities, and adversary emulation. His work involves dissecting complex attack chains and developing resilient defense strategies for clients in the finance, healthcare, and technology sectors.
Stay secure with DeepStrike penetration testing services. Reach out for a quote or customized technical proposal today
Contact Us