Notifications
Clear all
Topic starter
19/08/2026 4:06 pm
TL;DR: A year after PCI DSS requirements 6.4.3 and 11.6.1 became mandatory, Jscrambler argues that many merchant implementations still satisfy checklist review more easily than real-world attack pressure, especially when CSP, SRI, scanners, or proxies miss browser-side abuse. The practical test is whether controls detect behavior, not just permitted sources, and whether they survive selective evasion and compromised trusted scripts.
NHIMG editorial — based on content published by Jscrambler: PCI DSS 6.4.3 and 11.6.1 control effectiveness analysis
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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
👉 Read Jscrambler’s analysis of merchant approaches to PCI DSS 6.4.3 and 11.6.1 →
PCI DSS 6.4.3 and 11.6.1: are merchant controls actually working?
Explore further
19/08/2026 4:40 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: PCI DSS 6.4.3 and 11.6.1 expose the gap between compliant and secure
