Fortifying the Digital Checkout: Payment Page Security in E-Commerce

In our digital economy, online shopping has become second nature for consumers worldwide. Yet behind the seamless checkout experiences that we've come to expect lies a complex security challenge that merchants must navigate. With the rise of e-commerce payment processing comes the rise in threats from e-skimming attacks.

The Payment Card Industry Security Standards Council (PCI SSC) recently addressed this challenge with their comprehensive guidance document, "Payment Page Security and Preventing E-Skimming – Guidance for PCI DSS Requirements 6.4.3 and 11.6.1." This informative supplement provides crucial insights into implementing two key security requirements, 6.4.3 and 11.6.1, designed to protect payment card data during e-commerce transactions. 

In this article, we’ll explain the increase in e-skimming attacks, what you need to know to understand the PCI DSS requirements, and best practices for minimizing risk when using scripts on payment pages.  

The Rising Tide of E-Skimming Attacks 

E-commerce platforms have evolved dramatically in recent years, incorporating sophisticated functionality through various scripts. While these scripts enable interactive, feature-rich shopping experiences, they've also opened the door to a dangerous form of attack known as e-skimming. 

E-skimming occurs when malicious actors inject unauthorized code into payment pages, allowing them to silently harvest payment card details as consumers enter them, or during information transfers to payment processors. Modern websites rely heavily on scripts from both internal and external sources, creating a complex web of potential vulnerabilities. When these scripts aren't properly managed, they can lead to devastating data breaches that compromise consumer information and damage merchant reputations. 

These attacks typically manifest in two forms. In silent skimming attacks, malicious code operates invisibly in the background while consumers complete their transactions, unaware that their payment information is being stolen. Because everything appears to function normally from both the consumer's and merchant's perspectives, these attacks can persist undetected for months, steadily harvesting sensitive data. 

More disruptive but often more quickly discovered are double-entry attacks, where attackers insert counterfeit payment forms before legitimate ones. After consumers enter their payment details and encounter an error message, they're directed to re-enter their information in the merchant's actual form. These attacks are typically discovered faster either through consumer complaints about strange behavior or during routine testing of the website. 

These attacks aren’t just theoretical. Malwarebytes researchers uncovered a widespread malware campaign targeting a major e-commerce platform, with hackers injecting skimmer code into hundreds of online stores to steal customer payment information in real-time. The campaign works by exploiting vulnerabilities in websites using the software, where attackers inject a simple script tag that loads content from a remote hacker-controlled site. This malicious code can capture sensitive data including names, addresses, email addresses, credit card numbers, expiration dates, and security codes as shoppers type this information into payment screens—even before they click the submit button. The stolen payment information is then automatically redirected to command-and-control servers where it can be used for fraud or sold on the dark web. 
 
In another compromise, Recorded Future's H1 2024 Malware and Vulnerability Trends Report reveals how threat actors have refined their tactics in the first half of 2024, with infostealer malware dominating the threat landscape and LummaC2 emerging as the most active variant. The report highlights a staggering 103% increase in Magecart attacks targeting e-commerce platforms, likely due to vulnerabilities in widely used platforms and new e-skimming tools.

Additionally, cybercriminals and state-sponsored groups heavily exploited zero-day vulnerabilities in remote access and security solutions such as Ivanti Secure Connect, PAN-OS, and Microsoft Windows SmartScreen, with these vulnerabilities remaining attractive targets even after patches became available due to proof-of-concept exploits circulating online and the relative ease of exploitation by less sophisticated hackers. 

Understanding the PCI DSS Requirements 

Recognizing the growing threat, the PCI SSC introduced two complementary requirements in Data Security Standard (DSS) version 4.0. These requirements establish both preventative and detective controls to manage scripts and monitor for unauthorized changes. 

Requirement 6.4.3 focuses on proactive management of payment page scripts. It mandates that all scripts loaded by and executed in consumers' browsers be properly authorized, verified for integrity, and documented in an inventory with business or technical justification. This preventative approach aims to ensure only legitimate, necessary scripts are present on payment pages, reducing the attack surface available to malicious actors. 

Working in tandem with this preventative control, Requirement 11.6.1 establishes a detection mechanism to identify when unauthorized changes occur. This requirement calls for the deployment of systems that alert personnel to modifications of security-impacting HTTP headers and script contents on payment pages. Rather than attempting to prevent every potential unauthorized change, this detective control ensures that when changes do occur, they're quickly identified so appropriate action can be taken. These alerts must be generated at least weekly or at a frequency determined by the organization's risk analysis. 

Variation Among Payment Implementations 

The guidance document acknowledges that e-commerce payments aren't implemented uniformly across all merchants. It addresses four common scenarios, each with its own security considerations: 

• When merchants host their own payment forms, the payment entry fields reside directly on their web servers. In this scenario, merchants bear full responsibility for managing all scripts on their payment pages. 
  
  
• Many merchants choose to embed payment forms from third-party service providers (TPSPs) using inline frames, or iframes. These embedded elements create a "window" displaying content from the TPSP within the merchant's webpage. In such cases, merchants remain responsible for scripts on their parent pages that host the iframe, while TPSPs are responsible for securing scripts within the iframe itself. 
  
  
• Some implementations use redirection mechanisms, transferring consumers from the merchant's website to a separate payment processor's site. While merchants using this approach are responsible for scripts involved in the redirection process, the redirect scripts themselves aren’t subject to 6.4.3 and 11.6.1.  However, payment processors must meet these requirements for the target payment pages for any redirects. 
  
  
• In fully outsourced scenarios, payment processors handle all aspects of payment data collection and processing. Merchants using this approach – for example, by providing consumers with "pay now" links that lead directly to the processor's website – have no responsibilities related to Requirements 6.4.3 and 11.6.1. 

Practical Security Approaches for Implementation 

The recently released supplemental document offers detailed guidance on security controls and techniques to help organizations meet these requirements. Content Security Policy (CSP) is one powerful browser-native feature that allows websites to control which scripts can run on their pages. By setting policies dictating how content is loaded and executed, CSP can help with script authorization and integrity checking, though it requires complementary processes to fulfill all aspects of the requirements. 

Subresource Integrity (SRI) provides another layer of protection by comparing cryptographic hashes of resources against what browsers load, ensuring scripts haven't been tampered with. While effective for static scripts, SRI becomes challenging to implement for rapidly changing or dynamic third-party content. 

Webpage monitoring approaches examine payment pages as they appear in consumers' browsers, detecting malicious or unexpected script behaviors. These can be implemented through agent-based solutions that inject monitoring code into pages, or agentless solutions that simulate consumer journeys to observe loaded scripts and behaviors. 

For organizations with more complex infrastructures, proxy-based solutions can intercept traffic at the network edge, analyzing HTML and scripts before they reach consumers' browsers. These solutions can maintain comprehensive script inventories and enforce security policies in real-time. 

Best Practices for Reducing Risk 

The new guidance from the council emphasizes several foundational best practices for minimizing risk when using scripts on payment pages. Perhaps the most straightforward approach is simply limiting the number of scripts to those strictly necessary for payment functionality. Each additional script increases potential attack surface, so removing unnecessary ones represents a simple yet effective security measure. 

For scripts that must remain, isolating them in cross-origin or sandboxed iframes can confine them to controlled environments separate from sensitive payment elements. Organizations should also restrict script sources, limiting the domains from which scripts can be loaded to trusted providers only. 

Understanding normal script behavior through testing and baseline establishment helps organizations recognize when scripts are behaving suspiciously. Regular technical security assessments, including static code reviews and behavioral analysis, further strengthen defenses by identifying vulnerabilities before attackers can exploit them. 

Assessing Implementation and Compliance 

The supplement provides detailed guidance on assessment evidence that organizations should maintain to demonstrate compliance with Requirements 6.4.3 and 11.6.1. This includes documented policies and procedures, clearly defined roles and responsibilities, comprehensive script inventories with justifications, system configurations showing authorization and integrity methods, and records from monitoring activities. 

For Requirement 11.6.1 specifically, organizations should maintain evidence of their change and tamper-detection mechanism's configuration, monitoring coverage, alerting capabilities, and execution frequency. If an organization opts to perform these functions less frequently than weekly, they must document a targeted risk analysis justifying their approach. 

Implementing PCI SSC Guidance to Protect Payment Data 

As e-commerce continues to grow in importance, so does the sophistication of threats targeting payment data. The PCI SSC's guidance on Requirements 6.4.3 and 11.6.1 provides an excellent starting point for securing payment pages against increasingly common e-skimming attacks. 

By implementing proper script management, monitoring for unauthorized changes, and following the best practices outlined in the supplement, organizations can significantly reduce their risk of payment data breaches. The document emphasizes that while technology plays a crucial role, effective security requires a holistic approach combining proper policies, clear responsibilities, monitoring systems, and response procedures. 

For merchants, service providers, and assessors navigating these requirements, the guidance offers a valuable roadmap toward more secure e-commerce implementations. As attackers continue to evolve their techniques, this guidance provides a solid foundation for protecting both businesses and their customers from the growing threat of e-skimming attacks. 

If you’re ready to pursue PCI DSS Validation, or have any further questions about PCI DSS requirements, Schellman can help. Contact us today to learn more about the process or our services and we’ll get back to you shortly. In the meantime, discover other helpful PCI DSS insights in these additional resources:  

• Understanding SAQ A Eligibility for E-Commerce PCI Compliance 
• SAQ A Updates: Ensuring Your E-Commerce Site is Safe from Script Attacks 
• Important PCI DSS v4.0.1 Update for E-commerce Merchants 
• PCI DSS v4.0.1 Unveiled: What's New and What It Means for You