Notifications
Clear all
Topic starter
20/08/2026 5:37 pm
TL;DR: PCI DSS v4.0.1 now makes script inventory, justification, integrity checking, and tamper detection core expectations for payment pages, and Jscrambler’s analysis frames requirements 6.4.3 and 11.6.1 as an ongoing control problem rather than a one-time assessment. The practical challenge is less about passing a review and more about maintaining trustworthy client-side execution as third-party scripts, headers, and runtime changes keep evolving.
NHIMG editorial — based on content published by Jscrambler: PCI DSS v4 requirements 6.4.3 and 11.6.1 for e-skimming defence
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: What breaks when third-party scripts are not governed on payment pages?
A: When scripts are not governed, the browser becomes an uncontrolled access layer.
Q: Why do third-party scripts complicate PCI DSS compliance so much?
A: Third-party scripts complicate compliance because they extend trust outside the merchant’s direct codebase and can change without the merchant’s release process.
Q: How do organisations know whether client-side tamper controls are working?
A: They should be able to prove three things: every script on the page is inventoried and justified, unauthorized changes are detected reliably, and alerts lead to investigation before payment data is exposed.
Practitioner guidance
- Catalogue every payment-page script with explicit justification Build and maintain a live inventory of all scripts that execute in the browser, including third-party tags, with a business or technical reason for each entry.
- Add runtime tamper detection for security-impacting changes Monitor payment pages for script content changes, header modifications, and other tampering signals that could indicate e-skimming.
- Map control choice to site complexity and update cadence Use CSP and SRI where they fit, but do not rely on them alone for dynamic or third-party-heavy pages.
What's in the full article
Jscrambler's full article covers the operational detail this post intentionally leaves for the source:
- Side-by-side evaluation of CSP, SRI, scanner, agent, and proxy approaches for PCI DSS 6.4.3 and 11.6.1.
- Practical notes on how Jscrambler handles hybrid client-side protection and compliance workflows in live environments.
- The Scentbird example, including why the team chose the path it did and what the implementation experience looked like.
- Additional guidance on reducing manual authorisation work and managing changing third-party script inventories.
👉 Read Jscrambler's analysis of PCI DSS v4.0.1 requirements for e-skimming control →
PCI DSS v4.0.1 and e-skimming controls: are payment pages ready?
Explore further
20/08/2026 6:23 pm
PCI DSS v4.0.1 exposes a familiar governance gap: script trust is now a live control problem, not a procurement problem. Organisations have often treated third-party browser scripts as a web operations issue rather than an access-control issue. That mindset no longer holds when every script can touch payment data and every runtime change can undermine assurance. Practitioners should now treat the browser as a governed execution environment.
A question worth separating out:
Q: What should teams do when payment-page tampering is detected?
A: Teams should isolate the affected page, preserve evidence, identify the modified script or header, and determine whether customer data could have been exposed during the malicious execution window. Then they should rotate any related secrets, review third-party dependencies, and validate that the monitoring gap is closed before restoring normal checkout traffic.
👉 Read our full editorial: PCI DSS v4.0.1 shifts e-skimming defence to continuous script control
