PCI DSS 6.4.3 and 11.6.1 expose the gap between compliant and secure

At a glance

What this is: This is an analysis of how merchants are implementing PCI DSS 6.4.3 and 11.6.1, with the central finding that many controls look compliant but still fail under targeted client-side attack conditions.

Why it matters: It matters because payment-page integrity depends on detection, monitoring, and behavioural visibility, which directly affects how security teams assess script trust, third-party risk, and control effectiveness in payment environments.

👉 Read Jscrambler’s analysis of merchant approaches to PCI DSS 6.4.3 and 11.6.1

Context

PCI DSS requirements 6.4.3 and 11.6.1 were designed to close a governance gap that many merchant programmes still struggle with in practice: proving that payment-page controls work under attack, not just on paper. The first requirement is about authorising client-side scripts, while the second is about detecting unauthorised changes, and the hard part is connecting those requirements to controls that still function when attackers use the browser itself as the attack surface.

That challenge becomes sharper in environments with tag managers, third-party scripts, and complex payment flows, because the security question is no longer whether a script was allowed once, but whether it remains trustworthy in runtime. For identity and access practitioners, the intersection is real: client-side integrity depends on trusted script sources, delegated access chains, and control over who can modify what gets executed in the browser.

The article’s starting position is typical of modern merchant environments. Many organisations can describe a control strategy, but far fewer can demonstrate that the control still detects malicious behaviour after selective evasion, trusted-source compromise, or client-side injection.

Key questions

Q: What fails when payment-page controls only validate script source?

A: Controls that only validate source can miss malicious behaviour after a script is allowed to run. If a trusted CDN, tag manager, or third-party library is compromised, the browser still executes it. That is why runtime visibility matters. Security teams need controls that detect DOM manipulation, form hijacking, and unexpected data exfiltration inside real sessions.

Q: Why do CSP and SRI still leave gaps in merchant payment pages?

A: CSP and SRI are valuable, but they mainly control where code comes from and whether it matches an expected hash. They do not guarantee that the allowed code behaves safely after execution. Merchants with active payment pages, changing third-party scripts, and tag managers need additional detection to catch compromised but authorised scripts.

Q: How can security teams tell if a client-side monitoring approach is effective?

A: Look for evidence that the control detects behaviour in real user sessions, not just page loads. Effective approaches should alert on inline injection, cookie access, localStorage manipulation, and network abuse. If the vendor cannot show detections from actual session activity, the control may be compliant in theory but weak in practice.

Q: Who is accountable when payment-page integrity controls miss an attack?

A: Accountability sits with the merchant, its security leadership, and the assessment process that accepted the control design. PCI DSS requires merchants to implement and validate controls, but compliance alone does not prove detection. If the chosen model cannot see selective evasion or browser-side abuse, the governance failure is architectural, not procedural.

Technical breakdown

Why CSP and SRI struggle to prove runtime integrity

Content Security Policy and Subresource Integrity are both useful, but they solve different problems. CSP is primarily a source allowlist that blocks scripts from disallowed locations, while SRI hashes expected content so the browser can reject tampered files. Neither control reliably tells you what a script does after it is allowed to execute. That distinction matters because modern skimming attacks often abuse allowed sources, inline logic, or compromised third-party delivery paths. A control that validates identity and origin but not runtime behaviour can still leave payment data exposed.

Practical implication: treat CSP and SRI as baselines, then require monitoring that can detect malicious behaviour inside the browser.

How scanner-based detection misses selective client-side abuse

Agentless external scanners visit a payment page from a synthetic environment, which makes them easy to deploy but easy to evade. Attackers can geo-target malicious code, gate activation on user interactions, hide payloads behind authenticated sessions, or trigger behaviour only for real browsers. That means a clean scan result can coexist with live card skimming in customer sessions. The core limitation is visibility: scanners observe a sampled view of the page, not the exact runtime conditions that customers experience.

Practical implication: validate that monitoring covers authenticated, geofenced, and interaction-dependent attack paths, not only generic page loads.

Why browser-side behaviour detection changes the control model

Behavioural runtime monitoring shifts the question from who served the script to what the script actually did after loading. That includes DOM manipulation, form-field interception, cookie access, localStorage reads, and unexpected network requests. This is the key architectural difference between identity-based trust and behaviour-based security. The article’s strongest point is that payment-page integrity cannot rely on provenance alone, because authorized scripts can still be compromised. Runtime controls are therefore about continuous inspection of execution, not just approval of source.

Practical implication: prioritise solutions that inspect real user sessions and alert on behavioural drift, not just script inventory drift.

Threat narrative

Attacker objective: The attacker wants to capture payment details or related browser data while remaining invisible to controls that only validate source or scan from outside the session.

1. Entry begins when an attacker compromises a trusted script source, injects malicious browser code, or waits for an allowlisted third-party script to be altered.
2. Escalation occurs when the malicious code runs inside the browser and inherits trust from the merchant page, tag manager, or other authorised delivery path.
3. Impact follows when the script steals payment data through form hijacking, cookie access, localStorage manipulation, or browser-based command and control.

NHI Mgmt Group analysis

Source-based validation is no longer enough for payment-page security. The article shows why controls that only check whether a script is permitted or hashed can still fail when a trusted source is compromised. In practice, the governance gap is not policy creation but runtime assurance. For payment environments, the control question has shifted from approval to behavioural verification.

Selective evasion is the named failure mode merchants keep underestimating. Geotargeting, user-agent filtering, interaction gating, and authenticated-session triggers all allow malicious code to hide from routine inspection. That means merchants can pass a cursory assessment while remaining exposed to live attacks. QSAs and security teams should treat evasion resistance as a core requirement, not an edge case.

Browser execution is the real security boundary for client-side payment controls. The article correctly distinguishes between what is delivered and what is executed, and that distinction mirrors a broader identity lesson: trusted identity is not the same as trusted behaviour. For teams governing third-party scripts, this is the point where source trust, tag manager trust, and runtime trust must be separated.

Runtime monitoring is becoming the practical standard for proving 6.4.3 and 11.6.1 effectiveness. A static inventory or edge-based inspection can support compliance, but neither proves that malicious behaviour will be caught once code is already in the browser. The market is moving toward behavioural evidence, and practitioners should evaluate whether their control stack can actually detect abuse in-session.

What this signals

Payment-page integrity is moving toward evidence-based assurance, where teams must prove that controls can see what real users experience rather than what a scanner samples. That will push merchants to reassess whether their current model is built for prevention, detection, or both.

The named concept here is runtime trust gap: the difference between approving a script and detecting what it does once execution begins. As third-party ecosystems expand, that gap will matter as much in governance discussions as classic access control does in IAM.

Security teams should expect assessors to ask more pointed questions about selective evasion, session visibility, and alert quality. Programmes that cannot answer those questions with evidence will struggle to show that 6.4.3 and 11.6.1 are effective rather than merely implemented.

For practitioners

• Test controls against selective evasion Use geotargeted, authenticated, and interaction-dependent test cases to verify that detection still fires when malicious code hides from ordinary scans.
• Separate source trust from runtime trust Document which controls validate allowed script origin and which controls inspect actual browser behaviour, then close any gap between those two layers.
• Audit third-party script change paths Review tag managers, CDN-delivered assets, and external libraries for change control, because a trusted source can become the delivery path for malicious code.
• Require session-level evidence of detection Ask for last-alert examples, response logs, and proof that monitoring works inside real user sessions rather than only in synthetic scans.

Key takeaways

• The core problem is not understanding PCI DSS 6.4.3 and 11.6.1, but proving that merchant controls still work when attackers evade synthetic inspection and abuse trusted browser paths.
• Client-side integrity depends on runtime behaviour, not just allowed sources or script hashes, which is why source validation alone leaves a governance gap.
• Practitioners should validate selective evasion resistance, real-session visibility, and behavioural alerting before treating a payment-page control as effective.

Key terms

• Content Security Policy Bypass: A failure where an allowlist or browser content policy permits data to leave through a destination that should no longer be trusted. In AI agent attacks, this matters because outbound channels can be used to exfiltrate information after the model has already been steered into unsafe behavior.
• Subresource Integrity: Subresource Integrity is a browser mechanism that checks whether an externally loaded file matches an expected cryptographic hash. It reduces the risk of silently executing modified JavaScript from a CDN, especially when teams pin versions and avoid mutable tags.
• Client-Side Behavioural Monitoring: A control approach that watches what browser-executed code actually does, rather than only where it came from. It can detect form hijacking, DOM manipulation, and data exfiltration inside the user session, which makes it more useful for modern payment-page integrity problems.

What's in the full article

Jscrambler's full blog post covers the operational detail this post intentionally leaves for the source:

• Side-by-side assessment of CSP, SRI, scanners, proxies, and agent-based monitoring across detection coverage
• Concrete examples of evasion patterns such as geo-targeting, user-agent filtering, and interaction-gated payloads
• Practical QSA questions for checking whether a merchant's control stack can detect runtime abuse
• Implementation-specific distinctions between edge-layer inspection and in-browser behavioural monitoring

👉 The full Jscrambler post breaks down control trade-offs, evasive attack patterns, and assessment questions in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and IAM fundamentals. It helps security practitioners connect identity controls to the broader governance problems that shape modern security programmes.