Notifications
Clear all
Topic starter
20/08/2026 5:27 pm
TL;DR: PCI DSS v4 extends payment security expectations into the browser, where third-party JavaScript can now become the most visible and hardest-to-govern source of client-side risk, according to Jscrambler’s webinar with Marriott Vacation Worldwide. The practical shift is from backend-only compliance to continuous visibility, script-level control, and operational ownership of what executes on payment pages.
NHIMG editorial — based on content published by Jscrambler: Securing the Browser, How PCI DSS v4 initiated a client-side protection journey
By the numbers:
- 80% of organisations say third-party web applications increase their risk exposure, according to a recent industry benchmark.
Questions worth separating out
Q: How should organisations secure payment pages that rely on third-party JavaScript?
A: They should treat every script on a payment page as part of the control surface, then inventory it, assign ownership, and restrict its access to sensitive form data.
Q: What breaks when client-side controls are missing on payment pages?
A: Attackers can skim card data directly in the browser, bypassing backend monitoring, network controls, and server-side logging.
Q: How do you know if browser runtime protection is actually working?
A: Look for evidence that every payment page has a current script inventory, clear ownership, enforced policy review, and alerting on script changes.
Practitioner guidance
- Inventory every payment-page script Create and maintain a complete inventory of all JavaScript executing on pages that process card data, including third-party and legacy scripts that no longer have an obvious owner.
- Assign explicit ownership for client-side code Map each payment page and script to a business owner, technical owner, and review cadence so shadow IT pages and scripts do not remain ungoverned.
- Restrict script access to sensitive fields Apply browser-side controls that limit what individual scripts can read or transmit from payment forms, rather than relying only on network-layer inspection or blocking every third party.
What's in the full article
Jscrambler's full research covers the operational detail this post intentionally leaves for the source:
- Nine-month discovery workflow for mapping every page that accepts credit card data
- Operational examples of browser-side restrictions that block data access without breaking marketing or analytics
- How the team evaluated CSP, SRI, and CDN options before choosing a runtime approach
- The practical mechanics of continuous visibility across multiple brands and codebases
👉 Read Jscrambler's analysis of browser runtime controls for PCI DSS v4 →
Browser runtime security under PCI DSS v4: are controls keeping up?
Explore further
20/08/2026 6:16 pm
Browser runtime is now a governance boundary, not a delivery detail. PCI DSS v4 reflects a broader shift in security design: code executing in the browser can no longer be treated as outside the control perimeter. That matters because the browser is where delegated trust, third-party script execution, and payment data exposure intersect. For IAM and application security teams, the practical conclusion is that runtime access to sensitive fields must be governed as carefully as backend privilege.
A question worth separating out:
Q: Who is accountable when a third-party script exposes customer payment data?
A: Accountability sits with the organisation operating the checkout, even when a third party supplied the script or tag. PCI obligations do not transfer with outsourcing. Security, compliance, and product teams need explicit ownership for script approval, monitoring, and incident response because the browser is still part of the organisation’s control boundary.
👉 Read our full editorial: PCI DSS v4 pushes browser runtime security into the control perimeter
