Boost Security with PCI Requirements 6.4.3 and 11.6.1

TL;DR

• PCI DSS 4.0 Requirements 6.4.3 and 11.6.1 are safeguards against e-skimming and Magecart attacks.
• 6.4.3 focuses on managing scripts on payment pages, while 11.6.1 detects unauthorized changes.
• Both are vital for PCI DSS 4.0 compliance for websites, especially in e-commerce.
• Merchants and TPSPs share responsibility depending on payment page architecture.

Introduction

Who this guide is for:

Merchants, third-party service providers (TPSPs), CISOs, security architects, and e-commerce businesses preparing for PCI DSS 4.0 compliance.

Why it matters:

The shift from PCI DSS 3.2.1 to 4.0 introduces critical updates addressing today’s client-side threats like e-skimming and Magecart attacks. These attacks exploit scripts running in browsers to steal credit card data—undetectable to many traditional server-side defenses.

What you’ll learn:

This guide explores Requirements 6.4.3 and 11.6.1 in depth—explaining what they are, when they apply, who’s responsible, tools that help, and best practices for implementation.

What is PCI DSS 4.0 Requirement 6.4.3?

Definition:

Requirement 6.4.3 mandates that all scripts executing on payment pages must be:

• Authorized explicitly
• Verified using mechanisms such as Subresource Integrity (SRI) or Content Security Policy (CSP)
• Documented in an inventory with a valid business justification

Why it matters:

Client-side scripts are prime targets for attackers inserting malicious JavaScript. Without visibility and control, attackers can silently skim payment data as users type it in. PCI 4.0 turns the spotlight on this blind spot.

How to comply:

• Maintain a real-time inventory of all scripts on payment pages.
• Validate each script’s source, purpose, and modification status.
• Use cryptographic checks like SRI hashes or a strong CSP to ensure content integrity.

Example Use Case:

An e-commerce store embeds marketing, analytics, and checkout scripts. Under PCI DSS 4.0, it must:

• Approve each script (e.g., Stripe.js, Google Analytics)
• Apply CSP rules limiting script domains
• Ensure each script’s hash matches its original version

Tools that help:

• Client-side protection platforms (e.g., Feroot Security)
• Tag management auditing tools
• PCI DSS 4.0 6.4.3 software solutions for real-time script inventory and risk scoring

What is PCI DSS 4.0 Requirement 11.6.1?

Definition:

Requirement 11.6.1 focuses on change and tamper detection for scripts and HTTP headers on payment pages. It mandates:

• Alerting personnel to unauthorized alterations
• Scanning content at least weekly or as defined by your risk strategy

Why it matters:

Even with strict script approvals (6.4.3), attackers may exploit third-party scripts or compromise content delivery networks (CDNs). 11.6.1 catches what 6.4.3 might miss by monitoring for runtime anomalies.

How to comply:

• Implement real-time or scheduled scans of HTTP headers and script files
• Set up automated alerts for detected changes
• Use behavior-based threat detection to catch suspicious activity

Example Use Case:

A retail website is hijacked via a third-party vendor’s script. Although the script was previously authorized (6.4.3), it was later compromised. Requirement 11.6.1’s scanning mechanism flags the new unauthorized behavior.

Tools that help:

• Tamper detection solutions for web applications
• Script behavioral analysis platforms
• PCI DSS 11.6.1 compliance software with differential snapshot comparison and alerting

Who Is Responsible? Applicability Across Payment Flows

The responsibilities for meeting these requirements vary depending on how your payment pages are implemented. Understanding your architecture is essential to assign the correct compliance duties:

• Merchant-Hosted Payment Forms
  • Merchant: Fully responsible for managing all scripts on their webpages.
  • TPSP: Responsible for any scripts they provide (e.g., hosted SDKs or embedded services).
• Embedded Payment Forms (iframes)
  • Merchant: Responsible only for scripts on the parent page.
  • TPSP: Handles all scripts executed within the iframe itself.
• Redirection to a TPSP
  • Merchant: Responsible for scripts on the redirecting page (before user leaves).
  • TPSP: Responsible for all content, scripts, and security on the hosted payment environment.
• Fully Outsourced Merchant Website
  • Merchant: Not responsible for Requirements 6.4.3 and 11.6.1.
  • TPSP: Takes full responsibility for managing and monitoring all scripts and headers.

Internal tip: Check your merchant SAQ type (e.g., SAQ A-EP for merchant-hosted forms or SAQ D for custom web apps). These help determine the scope and applicability of PCI DSS 4.0 compliance controls.

Tools for PCI DSS 4.0 Compliance

Navigating script security and change detection is daunting without automation. These tools streamline compliance while boosting security posture:

Best PCI DSS 4.0 6.4.3 Tools:

• Script Management Platforms: Create a living inventory with audit logs.
• Browser Security Policies (CSP/SRI): Enforce script origin control.
• Client-Side Security Tools: Detects and blocks malicious script behavior.

Top PCI DSS 4.0 11.6.1 Tools:

• Header Monitoring Solutions: Track CSP, HSTS, and other headers.
• Real-Time Alert Engines: Notify stakeholders of unauthorized changes.
• Differential Analysis Scanners: Compare website snapshots over time.

Unified Platforms:

• Feroot offers end-to-end client-side monitoring and PCI DSS 4.0 reporting capabilities.

Best Practices for Staying Compliant

Security isn’t static. Here are expert-backed strategies for continuous compliance:

1. Minimize Script Footprint
   • Eliminate unnecessary third-party scripts
   • Use asynchronous loading when possible
2. Isolate High-Risk Elements
   • Use iframes for sandboxing
   • Implement subdomains for risky vendors
3. Apply CSP and SRI
   • Whitelist only trusted script sources
   • Use cryptographic hashing (SRI) for each file
4. Automate Script Inventories
   • Schedule weekly audits
   • Version control scripts and verify checksums
5. Collaborate with TPSPs
   • Demand shared responsibility agreements
   • Validate that your providers comply with Requirements 6.4.3 and 11.6.1
6. Monitor Continuously
   • Don’t rely on weekly scans alone—real-time tamper detection is more effective

FAQ

What is the main difference between Requirements 6.4.3 and 11.6.1?

6.4.3 prevents unauthorized scripts from being included; 11.6.1 detects unauthorized changes after the fact.

Do these requirements apply if I use hosted payment solutions like Stripe Checkout?

If the solution redirects customers away from your site, you may be out of scope for 6.4.3/11.6.1. But you still must secure any scripts on the redirecting page.

Can CSP and SRI alone satisfy 6.4.3?

No. While they’re required for script integrity, you must also authorize, document, and justify each script’s presence.

What if my TPSP fails compliance?

Responsibility still rests partially with you. Always vet vendors for PCI 4.0 readiness and insist on contractually enforced compliance.

How often should I audit scripts and headers?

PCI DSS mandates weekly at minimum, but continuous monitoring is recommended for real-time threat detection.