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

At a glance

What this is: This analysis says PCI DSS 6.4.3 and 11.6.1 can be met on paper while still leaving browser-side payment page abuse undetected.

Why it matters: For IAM, NHI, and security teams, the lesson is that compliance evidence must prove behavioural detection and resilience to compromised trusted components, not just source allowlisting.

Context

PCI DSS 6.4.3 and 11.6.1 create a governance gap when merchants treat script approval and script monitoring as the same control. Payment pages are now dynamic execution environments, so source allowlists, inventories, and point-in-time reviews can miss abuse that appears only in real user sessions or after a trusted component is compromised.

The identity angle is indirect but real: modern payment-page attacks often abuse trusted scripts, tag managers, and browser-side execution paths rather than classic user accounts. That means the assurance question is not just who may load code, but what that code is allowed to do once it is running, and whether monitoring can prove it during live customer interactions.

Key questions

Q: What breaks when PCI DSS 6.4.3 controls only prove script approval, not runtime safety?

A: The control breaks when a trusted script is approved at the source level but later behaves maliciously inside the browser. That leaves a merchant with evidence of permission, not evidence of safe execution. The practical failure is an authorised but compromised component that can skim data, alter forms, or call out unexpectedly without triggering a source-based control.

Q: Why do browser-side payment-page attacks survive scanners and proxy inspection?

A: They survive because many attacks are selective. They can wait for real users, login states, certain geographies, specific user agents, or interaction events before activating, while scanners and proxies only see a partial or synthetic view. If the control cannot observe live browser behaviour, it can miss the compromise entirely even when the page looks clean in testing.

Q: What are the signs that a merchant's PCI monitoring is too shallow?

A: Common warning signs include CSP with no violation monitoring, SRI used only on a handful of static scripts, manual inventories that are rarely updated, and scanners that cannot explain how they handle evasion. Another red flag is any solution that cannot show alerts tied to actual customer-session behaviour on payment pages.

Q: Should teams rely on CSP, SRI, or behavioural monitoring for PCI payment pages?

A: Use CSP and SRI as preventive baselines, but do not treat them as complete assurance. Behavioural monitoring is the stronger control when you need to detect compromised trusted scripts, inline injection, or browser-side exfiltration. In practice, the right answer is layered control, with runtime detection carrying the assurance burden.

Technical breakdown

CSP and SRI are prevention controls, not full detection

Content Security Policy and Subresource Integrity both constrain what code can load, but neither proves that authorised code remains safe after execution starts. CSP blocks unapproved sources and SRI checks a hash before delivery, yet both fail when a permitted source is compromised or when behaviour changes inside the browser after load. That is why they are useful baseline controls but weak standalone answers to PCI DSS 11.6.1, which expects detection and alerting on unauthorised modification. Practical assessment requires asking whether the control can observe runtime behaviour, not just initial trust.

Practical implication: Treat allowlisting and hashing as baseline controls, then add runtime monitoring that can see script behaviour after page load.

Why scanners and proxies miss browser-side abuse

External scanners and MITM or proxy-based inspection see a synthetic or transit view of the page, not the full behaviour of a live customer session. Attackers can evade those controls by geo-targeting, checking user agents, waiting for specific times, or triggering only after login or interaction. Proxy models also struggle with inline scripts, DOM-injected scripts, and exfiltration that stays entirely inside the browser through cookies, localStorage, or WebSocket-based command and control. In payment-page security, the line of sight problem is often the control failure, not the attack sophistication alone.

Practical implication: Validate that monitoring covers live browser behaviour, selective activation, and client-side exfiltration paths, not just fetched scripts.

Behavioural integrity closes the authorised but compromised gap

A script can be approved at the source level and still become dangerous later if a CDN, tag manager, or third-party dependency is compromised. Behavioural integrity looks at what the script actually does at runtime, such as reading payment fields, changing its action set, or initiating unexpected network calls. That is materially different from identity validation, which answers whether a script was allowed onto the page, not whether it stayed within its intended behaviour. For merchant pages, the useful question is whether the control can detect a trusted script turning malicious after initial trust was granted.

Practical implication: Use behavioural monitoring on payment pages so trusted scripts are continuously checked for activity that exceeds their approved purpose.

Threat narrative

Attacker objective: The attacker wants to harvest payment data or run browser-side skimming on real customer sessions without triggering the merchant's review process.

1. Entry begins when malicious or compromised code reaches a merchant payment page through a trusted script source, tag manager, inline injection, or third-party dependency.
2. Credential or data capture occurs inside the browser when the script targets payment fields, cookies, localStorage, or user interactions that external controls may not observe.
3. Impact follows when card data is skimmed or command-and-control traffic remains active long enough to evade point-in-time review and synthetic scanning.

Breaches seen in the wild

• Sentry MCP Agentjacking 2026: Researchers showed a fake Sentry error, posted with a public DSN, could make AI coding agents run attacker code with developers' credentials.
• PocketOS database deletion incident: An AI coding agent found an over-privileged Railway API token in the codebase and deleted PocketOS production data and backups in nine seconds.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Compliance evidence is not the same as control evidence: PCI DSS implementations can look complete while still failing under live browser pressure. That gap appears when merchants prove that scripts were approved, but not that they were continuously observed doing safe work. The practical lesson for security and governance teams is that control design must be measured against runtime behaviour, not checklist completion.

Browser-side payment security is now a behaviour problem, not a source problem: source allowlists and hashes are necessary but insufficient because attacks increasingly abuse trusted execution paths. Once a permitted script is compromised, the relevant governance question becomes what that script does in the customer session. Teams should treat runtime behaviour as the control boundary, especially on high-volume checkout pages.

Selective evasion exposes a verification trust gap: scanner-based assurance assumes the tested page is representative of the real one, but attackers can change what different users see. Geo-targeting, login gating, user-agent filtering, and interaction triggers create a gap between synthetic inspection and actual compromise conditions. Practitioners need to assume that clean scans can coexist with active skimming unless monitoring occurs in real sessions.

Authorised script trust must now be conditional: a trusted tag manager or CDN cannot be treated as a permanent security certificate for everything it loads. The stronger control model is to approve sources and then verify behaviour continuously, because the compromise point often arrives after initial authorisation. For PCI programmes, that changes the governance question from who may load code to whether the code stays inside its intended boundary.

What this signals

Runtime script governance is becoming the decisive control boundary: merchants can no longer assume that source approval alone proves a payment page is safe. The operational question is whether controls can observe what the browser actually executes, especially when trusted third-party code changes behaviour after approval.

PCI programmes should separate prevention from verification: allowlisting, hashing, and inventories reduce exposure, but they do not prove that live sessions are clean. For teams responsible for checkout risk, the governance model now has to include runtime verification of script behaviour, not just pre-deployment review.

For practitioners

• Tighten script governance beyond source allowlists Require merchants to prove both script authorisation and runtime visibility for payment pages, especially where third-party tags change frequently.
• Test controls against selective evasion Ask vendors and internal teams how monitoring handles geo-targeting, login-gated flows, user-agent filtering, and interaction-dependent activation.
• Review whether scanning includes live browser behaviour Verify that alerting can see cookie access, DOM mutation, form hijacking, and client-side exfiltration rather than only fetched scripts.
• Challenge trusted-source assumptions Treat compromised CDN, tag manager, and analytics scripts as expected failure modes and confirm the control can flag changed behaviour after initial approval.

Key takeaways

• PCI DSS 6.4.3 and 11.6.1 can be implemented in ways that look compliant while still missing browser-side abuse on payment pages.
• The most common failure is assuming that source trust, script approval, or point-in-time review proves safe execution in live customer sessions.
• Runtime behavioural monitoring is the control that most directly addresses compromised trusted scripts, selective evasion, and client-side exfiltration.

Key terms

• Browser-side Skimming: Browser-side skimming is the theft of payment or form data from within a user's browser session rather than from a server or network perimeter. Attackers abuse trusted scripts, DOM changes, or client-side storage to capture information while avoiding controls that only inspect traffic or approved sources.
• Runtime Behaviour Monitoring: Runtime behaviour monitoring is the practice of watching what an identity actually does during execution, not just what it was configured to do. For AI agents, this means tracking tool calls, session activity, data volume, and unusual action sequences so semantic abuse can be detected in flight.
• Semantic Evasion: Semantic evasion is the practice of hiding malicious intent inside content that appears legitimate to normal filters or classifiers. In AI systems, the danger is that the text may look harmless syntactically while still carrying instructions designed to steer retrieval, generation, or data disclosure.
• Content Security Policy Directive: A Content Security Policy directive is a rule in the policy that tells the browser what kind of content may load and from where. Directives such as script-src or img-src narrow execution and retrieval paths, helping teams define a trusted set of sources and reduce exposure to injected content.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance and workload identity alongside the access controls that underpin broader identity programmes. It helps practitioners connect operational control design to the governance decisions their programmes already make.