Client-Side Security: PCI DSS Requirements 6.4.3 and 11.6.1

For most of the history of the Payment Card Industry Data Security Standard, the assessor’s gaze rested on the server: the systems that stored, processed, or transmitted cardholder data inside your own walls. Attackers have moved on. The modern card-theft campaign rarely touches your database at all. Instead it targets the customer’s own browser, where your payment page assembles itself from many different sources and runs whatever code it is told to run.

This is digital skimming, commonly grouped under the label Magecart. Rather than breaching your infrastructure, the attacker compromises a script that your payment page already trusts: an analytics tag, a chat widget, a font loader, a third-party library served from a content delivery network. The moment that tampered script executes in a shopper’s browser, it can read the card number, the expiry date, and the security code straight from the form fields, then quietly send a copy to the attacker. Your server logs show nothing unusual. Your card data environment was never touched. The theft happened entirely on the client side.

PCI DSS v4.0 answered this with two requirements aimed squarely at the browser: Requirement 6.4.3, which governs the scripts that are permitted to run on your payment page, and Requirement 11.6.1, which detects tampering with the page and its HTTP headers as the customer actually receives them. Both were future-dated when v4.0 was published, giving organisations time to prepare. That grace period is over. Since 31 March 2025 both requirements have been mandatory for every in-scope entity, save for the specific carve-out for merchants who qualify for the revised SAQ A, which we cover below. If you take card payments through a browser and you have not implemented these controls, you are non-compliant today. This article is part of our wider PCI DSS resource hub, and sits alongside our overview of the future-dated requirements now in force.

How a client-side skimming attack actually works

To understand what these requirements defend against, it helps to walk an attack chain from start to finish. Suppose your checkout page loads a JavaScript file from a third-party vendor to power a customer-support chat bubble. You did not write that code, you do not host it, and you do not control the server it comes from. Your page simply includes a script tag pointing at the vendor’s domain, and the shopper’s browser dutifully fetches and runs whatever is at that address.

1. The attacker compromises the vendor, not you. They gain write access to the chat widget’s source file sitting on the vendor’s delivery network.
2. They append a small, obfuscated payload to the legitimate script. The chat widget still works exactly as before, so nobody notices anything is wrong.
3. On your checkout page, that script now runs with the same privileges as any other script on the page. It attaches a listener to your payment form’s input fields.
4. As the shopper types their card number, the payload harvests each keystroke, or reads the full field values when the form is submitted.
5. The stolen data is encoded and sent to an attacker-controlled server, often disguised as a routine analytics or image request so it blends into normal traffic.

Notice what never happens: the attacker never logs into your systems, never queries your database, and never trips a server-side intrusion alert. The compromise lives in code that your own page invited in. This is why the two new requirements operate at the browser, and why they address different questions. Requirement 6.4.3 asks what code is allowed to run. Requirement 11.6.1 asks whether what was delivered has been tampered with. You need both, because each closes a gap the other leaves open.

Requirement 6.4.3: authorise, assure, and inventory every script

Requirement 6.4.3 applies to every script that is loaded and executed in the payment page within the consumer’s browser. For each such script, you must be able to demonstrate three things to your assessor.

• Authorisation. Each script is explicitly authorised. Somebody with the appropriate responsibility has confirmed that this script is meant to be on the payment page. Scripts do not appear by accident or by a developer’s convenience; their presence is a deliberate, recorded decision.
• Integrity assurance. You have a method to assure the integrity of each script, so that the code running in the browser is the code you approved and has not been altered. This is the control that would have caught the tampered chat widget in the example above.
• Inventory and justification. You maintain an inventory of all scripts, and for each one you record a written business or technical justification explaining why it needs to be there. If a script cannot be justified, it should not be on the payment page.

The practical force of 6.4.3 is that it makes you confront how much third-party code your checkout actually loads. Many organisations are surprised to find analytics tags, marketing pixels, testing tools, and libraries pulled in by other libraries, all executing alongside the payment form. Every one is an entry point, and every one now needs a name, an owner, a justification, and an integrity check.

Requirement 11.6.1: detect change and tampering in what was delivered

Where 6.4.3 controls what you intend to run, Requirement 11.6.1 verifies what was actually delivered to the shopper. It requires you to deploy a change-and-tamper-detection mechanism that alerts personnel to unauthorised modification, including indicators of compromise, of two things: the HTTP headers of the payment page, and the contents of the payment page as received by the consumer browser.

The emphasis on “as received by the consumer browser” is deliberate. It is not enough to check the file on your own web server. The mechanism must reflect the page as the customer sees it, because that is where injected skimming code appears and where header manipulation (for example, weakening a security policy) can be observed.

The mechanism must be evaluated at least once every seven days. Alternatively, you may set the frequency according to a Targeted Risk Analysis performed under Requirement 12.3.1. If you choose to move away from the default weekly cadence, that decision must be documented, justified, and defensible; a Targeted Risk Analysis is not a way to simply do less, but a way to match monitoring frequency to your actual risk. We explain the method in detail in our Targeted Risk Analysis guide.

Detection is only half the control. Requirement 12.10.5, part of your incident response programme, was updated so that it now explicitly requires monitoring and responding to alerts from the 11.6.1 change-and-tamper-detection mechanism. An alert that nobody watches or acts on satisfies neither requirement. The tamper-detection signal has to feed a process that a person owns and follows.

How to implement 6.4.3 and 11.6.1

There is no single product that discharges these requirements, and the standard is deliberately technology-neutral. In practice, organisations combine several techniques. Each has strengths and limits, and a control that looks convenient can leave a requirement only partly met.

The pattern most assessors expect to see is a layered one: CSP and SRI to constrain and verify what loads, disciplined tag-manager governance to keep the inventory honest, and a monitoring capability to catch what slips through and satisfy the tamper-detection requirement. No single row of that table is sufficient on its own.

The SAQ A eligibility change

There is one important exception, and it is widely misreported, so be precise here. In January 2025 the PCI SSC published a revised Self-Assessment Questionnaire A, effective 31 March 2025. The revised SAQ A removed Requirements 6.4.3, 11.6.1, and 12.3.1 from its scope. Merchants who genuinely qualify for the revised SAQ A therefore do not need to implement 6.4.3 or 11.6.1.

In their place, the revised SAQ A added a new eligibility criterion. To use it, the merchant must confirm that its site is not susceptible to attacks from scripts that could affect the e-commerce system, and that all elements of the payment page or pages delivered to the customer’s browser originate only and directly from a PCI DSS compliant third-party service provider or payment processor. This covers both the full redirect model and the embedded iframe model. The PCI SSC later published an FAQ clarifying how this eligibility criterion should be understood.

The logic is straightforward once you separate the two cases. If you outsource the entire payment page to a compliant provider, so that no cardholder data ever passes through code you control, the browser-based script risk sits with the provider and the new eligibility criterion applies to you instead. If any element of your payment page originates from your own environment, you are almost certainly not eligible for the revised SAQ A, and Requirements 6.4.3 and 11.6.1 apply to you in full. Many merchants assume they are SAQ A when their integration does not actually meet the criterion. If you are unsure which questionnaire fits your setup, our SAQ Selector tool will walk you through it.

The PCI SSC has answered the obvious follow-up question, how a merchant actually demonstrates that its site “is not susceptible to script attacks”, in FAQ 1588. Three points from it are worth knowing. First, the scripts criterion is aimed at merchants whose own webpage embeds the payment form from a third party, typically in an iframe; a merchant that fully redirects customers to the provider’s page is not the target of this criterion. Second, an iframe merchant can meet it in either of two ways: by applying the protective techniques described in Requirements 6.4.3 and 11.6.1 to its own page (implemented in house or by a third party), or by obtaining written confirmation from its PCI DSS compliant provider that the embedded solution, implemented per the provider’s instructions, includes protection against script attacks. Third, providers of non-payment scripts on your site (analytics, for example) are not treated as payment service providers for SAQ A purposes, provided their scripts cannot affect the security of account data. As the FAQ itself notes, your acquirer has the final say on which SAQ you may use, so confirm your validation route with them.

One related misconception is worth heading off while we are here: qualifying for SAQ A does not exempt you from external vulnerability scanning. The Council confirmed in FAQ 1604 that quarterly ASV scans apply to redirect and iframe merchants too, and we explain what that means in practice in our article on ASV scans for SAQ A merchants.

A practical implementation checklist

Use the following as a working sequence. It moves from discovery, through control, to the ongoing operation the standard expects.

1. Confirm your correct validation route first. Establish whether you genuinely qualify for the revised SAQ A. If you do not, 6.4.3 and 11.6.1 apply and the remaining steps are for you.
2. Discover every script that executes on your payment page as rendered in a real browser, including scripts loaded indirectly by other scripts.
3. Build a script inventory. For each entry, record the source, the owner, and a written business or technical justification. Remove anything that cannot be justified.
4. Authorise the remaining scripts through a defined approval step, so their presence is a recorded decision rather than an accident of development.
5. Apply integrity assurance. Use Subresource Integrity where the file is stable, and choose an appropriate integrity method for scripts that cannot be pinned by hash.
6. Deploy and tune a Content Security Policy to restrict script sources to your approved list, testing carefully to avoid breaking legitimate functionality.
7. Govern change through a controlled tag manager or equivalent, so new scripts cannot reach the payment page without passing your approval and inventory process.
8. Deploy a change-and-tamper-detection mechanism that evaluates the payment page contents and HTTP headers as received by the consumer browser.
9. Set the evaluation frequency. Default to at least once every seven days, or document a Targeted Risk Analysis under 12.3.1 if you adopt a different cadence.
10. Wire alerts into incident response under Requirement 12.10.5, with a named owner and a defined procedure for triaging and acting on them.
11. Keep evidence. Retain your inventory, justifications, policy configuration, and alert-handling records so you can demonstrate ongoing operation, not just a point-in-time setup.

Frequently asked questions

Do these requirements apply if my payment page uses an iframe from my processor?

It depends on whether every element of the payment page delivered to the browser originates only and directly from a PCI DSS compliant provider. If your integration meets the revised SAQ A eligibility criterion, which covers both redirects and embedded iframes, then 6.4.3 and 11.6.1 do not apply to you. If your own page hosts or assembles any part of the payment experience around that iframe, they very likely do. The detail of your integration decides it, so confirm it carefully rather than assuming.

Is a Content Security Policy enough to satisfy Requirement 6.4.3?

No. A CSP restricts which sources may load scripts, which supports the authorisation element, but it does not assure the integrity of a script that comes from an approved source. If a trusted vendor’s file is compromised, a CSP will still permit it to load. You also need an integrity mechanism, such as Subresource Integrity, and a maintained inventory with justifications to cover all three parts of the requirement.

How often must the tamper-detection mechanism run under 11.6.1?

At least once every seven days by default. You may instead set the frequency using a Targeted Risk Analysis performed under Requirement 12.3.1, but that analysis must be documented and defensible. It exists to align monitoring with your genuine risk, not to justify less frequent checking without cause.

What happens if my tamper-detection tool raises an alert?

Requirement 12.10.5 was updated so that your incident response programme must explicitly monitor and respond to alerts from the 11.6.1 mechanism. An alert on its own is not a control. A named owner has to receive it, triage it, and follow a defined process to investigate and contain a suspected compromise. Detection and response together are what the standard requires.

How Cianaa can help

As an independent QSA practice serving businesses across New Zealand and Australia, Cianaa helps you determine which validation route genuinely applies to you, scope your payment-page script risk, and implement 6.4.3 and 11.6.1 in a way that will stand up to assessment rather than merely look tidy. Whether you need to confirm SAQ A eligibility or build a full client-side control set, we can guide the work end to end. To discuss your situation with a Principal Assessor, get in touch with our team.