Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

We see the same pattern across healthcare clients. The servers are locked down, databases encrypted, and GRC documentation is in order. Then we check the browser layer and find a Google Analytics pixel quietly sending appointment URLs and other PHI to third-party servers without a BAA.

By the time you reach PCI DSS 4.0.1 Requirements 6.4.3 and 11.6.1, the easy wins are behind you. This is the point where compliance turns into configuration. Tag managers, consent scripts, and payment flows all intersect here, and the guidance feels just vague enough to slow everything down. Which tag rules belong in scope? How do you prove a script was authorized? What’s the right way to detect a change without flooding alerts?

Every time someone clicks “accept cookies,” a new layer of risk begins. What appears to be a simple consent interaction can activate dozens of unseen third-party scripts that collect, share, or store user data beyond your control. For marketers, cookies power analytics and personalization. For privacy and security professionals, they often create compliance gaps and data-security blind spots.

Learn how to make your website HIPAA compliant in 2025 with 30+ checklist items, from BAAs and access controls to client-side monitoring and audit-ready evidence.

PCI DSS 4.0.1 compliance becomes manageable once you recognize that each tool protects a different layer, and the strongest programs combine them thoughtfully. With Requirements 6.4.3 and 11.6.1 now bringing the browser into focus, organizations can finally see the complete picture they need.

Most organizations begin their PCI DSS planning with what’s easiest to define: the Qualified Security Assessor (QSA) fee. As the process unfolds, other costs come into view, from mapping data flows to preparing evidence. Seeing the full picture early helps teams plan with confidence.

Modern checkout pages have evolved from static forms into dynamic ecosystems where dozens of third-party scripts run alongside first-party code. This complexity expands the attack surface and challenges traditional defenses designed for fixed perimeters. PCI DSS 6.4.3 was introduced to address that shift, emphasizing continuous oversight of browser-executed scripts and the integrity of client-side behavior.

Most modern sites run significant third-party code in the user’s browser. The Web Almanac 2022 reports that the top 1,000 sites load an average of 43 third-party domains on mobile and 53 on desktop, expanding the surface for JavaScript injection attacks and supply-chain tampering. In parallel, real e-commerce compromises continue to surface. Sansec has identified more than 70,000 websites that suffered Magecart e-skimming over time.

Preparing for PCI DSS 4.0.1 can feel complex, especially when so much of compliance now lives in the browser. Your assessor’s main goal is simple: to confirm that your controls are not only in place but also working as intended. Two requirements matter most for e-commerce environments. Many organizations start with Content Security Policy (CSP). It’s a sensible place to begin because CSP gives browsers a set of rules about what content to load.

According to Web Almanac, the top 1,000 websites load an average of 43 third-party domains on mobile and 53 on desktop, each a potential entry point for supply-chain tampering. A separate analysis found that most enterprise sites include 12 third-party and 3 fourth-party scripts in sensitive user journeys. That’s 15 external execution paths per transaction, and every one of them runs in the same browser as your checkout.