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.
Editorial analysis by NHI Mgmt Group, based on content published by Jscrambler: “One Year of 6.4.3 and 11.6.1: A QSA’s Guide to Vendor Approaches”.
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.
Q: Why do browser-side payment-page attacks survive scanners and proxy inspection?
A: They survive because many attacks are selective.
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.
Practitioner guidance
- 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.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:40 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: PCI DSS 6.4.3 and 11.6.1 expose the gap between compliant and secure