Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Formjacking involves malicious code injected into payment forms that captures credit card data during transactions. The form functions normally, the payment completes, and nothing unusual appears in server logs. This happens in the browser, outside the reach of traditional server-side security controls. PCI DSS 4.0 requirements 6.4.3 and 11.6.1 extend compliance to the client side to address this.

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.

Many teams believe that cross-site scripting, or XSS, is a problem of the past. Modern frameworks promise built-in protections, and developers often assume the browser will handle the rest. The reasoning sounds logical: if React auto-encodes output, XSS can’t happen. However, XSS prevention doesn’t work on assumptions; it works on visibility. We’ve learned that XSS prevention is about maintaining continuous control over the browser environment where your application runs.

Many teams assume that embedding payment forms in an iframe keeps them compliant with PCI DSS 4.0.1, Requirement 6.4.3. The reasoning sounds logical – compliance seems guaranteed if card data never reaches your infrastructure. However, iframe payment security PCI DSS 6.4.3 doesn’t work on assumptions; it works on control. The responsibility shifts to new layers of your website’s supply chain.

PCI DSS 4.0.1 became mandatory on March 31, 2025, bringing in 47 new requirements that fundamentally changed how compliance works. Organizations that treated PCI as an annual audit exercise now face a standard that expects real-time visibility into payment pages. Requirements 6.4.3 and 11.6.1 are the most impactful additions, which require real-time visibility into scripts and payment page changes. A spreadsheet updated quarterly can’t deliver that.