Table of contents

Client-side attacks are one of the most common ways payment data is compromised today. PCI DSS v4 reflects this reality by extending security expectations to the browser and payment pages, where JavaScript executes and sensitive data is exposed.


In our recent webinar, Securing the Browser: How PCI DSS v4 Initiated a Client-Side Protection Journey, Jscrambler’s Product Marketing Manager, Katia Kupidonova, was joined by TJ Goldsmith, PCI Compliance Director at Marriott Vacation Worldwide (MVW), to discuss what this shift means in practice and how organizations can start addressing client-side risk in a structured, sustainable way. 


Below are four important takeaways from the session.


Why PCI DSS v4 forces a rethink of browser runtime security


For years, PCI compliance focused primarily on backend infrastructure: servers, networks, and storage. Meanwhile, attackers quietly shifted their focus to the client side, exploiting JavaScript running in users’ browsers to skim payment data without triggering traditional security controls. PCI DSS v4 closes this gap. It makes clear that if code executes in the browser on a payment page, it is within the security perimeter. MVW is part of a complex business conglomerate that prioritized PCI DSS as part of their client-side protection journey. 


4 Key takeaways: third-party JavaScript is the largest source of client-side risks


Most payment pages rely on a complex ecosystem of third-party scripts for analytics, personalization, and marketing. While these tools enable rapid business growth and require frequent updates, they also introduce risks that are often poorly understood and rarely monitored.


On this point, TJ Goldsmith shared that during the nine-month discovery process to track every page that accepted credit card data, they found shadow IT - “pages and scripts that nobody really owned anymore, but they were still processing credit cards.”


In large organizations like Marriott, with different brands, different codebases, and vendors, marketing teams change things every month. When third-party JavaScript is introduced through decentralized workflows, it becomes the largest and least visible source of client-side risk.


  1. Enterprise-scale visibility strengthens security posture

MVW operates across 160 documented card data flows, 15 unique codebases, and multiple brands. With continuous client-side visibility now in place with Jscrambler, MVW's PCI team can bring real technical data into broader security discussions: “With such little effort on our part, we’re able to bring real technical data to the table and drive improved security posture.” Companies can’t secure what they can’t see. 


  1. Granular control without interrupting the business is essential

Rather than blocking third-party scripts outright, which could disrupt marketing, analytics, or even the customer experience, the platform provides fine-grained control to restrict third-party scripts from accessing data. As TJ Goldsmith shared, “You can go all the way down to that one script and decide what you want the tool to do with it.”


Third-party vendors can continue functioning while the sensitive data they attempt to exfiltrate is restricted. This flexibility ensures compliance and protection without impacting performance or customer interactions.


  1. Automation eliminates the manual compliance burden

Before selecting a dedicated client-side protection solution, MVW evaluated alternatives such as CDN capabilities and implementing CSP or SRI controls. However, those approaches would have required significant manual oversight and ongoing maintenance.


As Goldsmith explained, compliance is managed internally by a very small team: “Even though we're a relatively large company, we do self-assess PCI compliance here. [Myself] and my little team manage the compliance work for all six entities simultaneously.”


Manually maintaining CSP policies, validating script hashes, and reviewing script inventories across that scale would have created an unsustainable compliance burden. Instead of adding operational complexity, MVW needed automation that satisfied PCI DSS v4 requirements without requiring constant manual intervention.


  1. Client-side protection is a journey

PCI DSS v4 can serve as a practical starting point for client-side protection. The standard provides a clear framework that encourages greater visibility, continuous monitoring, stronger governance, and closer collaboration across security, compliance, and development teams. Organizations that use PCI DSS v4 as a catalyst for these efforts are better positioned not only to meet compliance requirements but also to meaningfully reduce real-world risk. Regardless of where an organization stands today, it’s never too late to begin implementing more resilient client-side security.



As discussed during the webinar, MVW’s client-side protection journey highlights what’s possible when organizations move beyond compliance and focus on securing what actually runs in the browser.


By working with Jscrambler, MVW gained continuous visibility into client-side JavaScript, detected unexpected and risky script behavior in real time, and established controls aligned with PCI DSS v4 requirements, without disrupting development or marketing teams. This approach allowed MVW to reduce client-side risk while maintaining the agility required by modern digital businesses.



The same challenges MVW faced are shared by many organizations today: growing reliance on third-party scripts, limited browser visibility, and increasing pressure to demonstrate compliance with standards like PCI DSS v4. Companies are looking to reduce tooling and improve efficiency with easy-to-use, straightforward solutions.


Jscrambler helps address these challenges by providing a scalable, runtime approach to client-side protection that supports security, compliance, and business teams alike.


For organizations beginning or advancing their client-side protection journey, Jscrambler offers a practical path forward: from visibility and monitoring to governance and real-time protection, always with seamless integration and constant customer support, focused on securing the browser, where modern attacks occur.



Must read next

Enhancing E-Commerce Security with PCI DSS v4: the Role of Advanced Solutions like Jscrambler
BLOG ARTICLE

Enhancing E-Commerce Security with PCI DSS v4: the Role of Advanced Solutions like Jscrambler

June 11th, 2024

Dedicated Client-Side Security Tools to Comply with PCI DSS Requirements 6.4.3 and 11.6.1
BLOG ARTICLE

Dedicated Client-Side Security Tools to Comply with PCI DSS Requirements 6.4.3 and 11.6.1

December 16th, 2025

PCI DSS 4.0.1 Released: Changes to Requirements 6.4.3 and 11.6.1
BLOG ARTICLE

PCI DSS 4.0.1 Released: Changes to Requirements 6.4.3 and 11.6.1

January 6th, 2026

Subscribe to Our Newsletter