In today's digital age, e-commerce has become an integral part of our lives. Shopify reports that e-commerce revenue is projected to hit $4.28 billion this year, grow by 13% in 2024, and another 12% in 2025. At the end of that forecast, the rules will be different for how merchants accept payment.
The Payment Card Industry Data Security Standard (PCI DSS) 4.0 update takes effect in March 2025 and is meant to introduce significant security updates for merchants worldwide. One of the aims of the update is to significantly reduce Magecart attacks — e-skimmers that strip the personal data that gets input on e-commerce checkout pages. Visa’s Biannual Threats Report shows skimming cases skyrocketed 174% last June to November over the previous six-month span, from December 2021 to May 2022.
One of the most important new requirements is 6.4.3, which mandates that organizations manage third-party scripts on payment pages. Plenty of ink has been spilled about the PCI DSS changes, but many articles fail to address what this really means for those that need to comply with them. Let’s dig in on why this new DSS matters, how it aims to combat threats like Magecart attacks, and how merchants should move forward.
The Risk of Third-Party Scripts
Third-party/JavaScript tags are used ubiquitously by e-commerce websites. They can help marketing efforts by tracking potential shoppers’ movements and sharing deals related to the pages they visit, contacting them after they leave checkout pages and upselling related products. Scripts can create a personalized shopping experience, and Magecart attacks show there’s a potential price to pay for attempting to increase conversions.
Web developers may consider these scripts harmless and not consider their effect on a site’s attack surface, but in reality, these scripts are a huge blind spot. Adding JavaScript is like adding a black box application to the payment process. Many marketing websites offer JavaScript for these pages, but those pieces of code aren’t vetted or in a central location where scanners can easily find them.
Using JavaScript has become the wild, wild west — they can record keystrokes and record user movement, but the site that implements them usually doesn’t have oversight into their security. The third party that developed the JavaScript has visibility, and attackers are breaching these third-party scripts to exfiltrate shoppers’ payment information. These Magecart-style attacks aren’t new, but they’re still effective.
Canada’s largest alcohol retailer recently disclosed a breach it said affected customers over a five-day span. In this case, malicious code was injected inside a Google Tag Manager (GTM) tag, an oft-used tool by e-commerce sites. According to a report from Recorded Future, there were more than 1,500 unique domains used in Magecart attacks last year that infected more than 9,000 different e-commerce sites.
What 6.4.3 Requires
The checkout page is where credit card information is transferred, which is why PCI focused its efforts there. The recommendations would be best served across an entire site, but checkout pages are the new table stakes PCI has set to elevate e-commerce security.
The intent of requirement 6.4.3 is to get merchants to understand what third-party scripts they use and what they do, a tall order for many merchants. In security circles, these are common-sense measures to take, but they’ve never been called out by PCI previously.
PCI’s defined approach is to analyze every script that goes into the checkout page and document and justify why those scripts are necessary. It also requires a method to monitor those scripts and ensure they don’t change. If a third party does make a change to its JavaScript, merchants that use them need to document and justify the changes.Automated tools can monitor the integrity of JavaScript, or even block it. Content security policies can also be set not to execute JavaScript if changes are made. But those tools aren’t foolproof.
Content security policies and integrity checkers that are built into browsers only give one layer of security and can become ineffective as JavaScript becomes complex or layered. For instance, let’s say you put JavaScript on a website and perform an MD5 integrity check. If the file changes, the integrity check will say it has been tampered with. But JavaScript can be nested inside other JavaScript, which would bypass the integrity check. PCI calls this a “fourth party.”
Instead of trusting third (or fourth) parties, many organizations may opt to just disable JavaScript altogether, even if the user experience takes a hit. A small- or medium-sized business that doesn’t want to sacrifice the customization scripts offer may prefer to use an external shopping cart like Shopify, which will be under the microscope to ensure it is meeting compliance.
How to Move Forward
Security is an increasingly important factor in the e-commerce landscape. Even tech titans are making headlines with how seriously they’re taking it — Google recently suspended Pinduoduo after malware was found in the software.
And JavaScript is increasingly used as a vector to attack, even outside the e-commerce sphere. So, what are organizations left to do?
Vulnerability scanners look for flaws in custom and server-side code, but essentially ignore what’s in JavaScript. Most people don’t know that’s being skipped. It’s difficult to inspect JavaScript, and experienced penetration testers know what to look for in those files. They understand what organizations want the script to do and what developers were thinking as they wrote the code. Some advanced web application scanners can also inventory and identify third-party scripts, monitor for change, and alert when new scripts are introduced.
The scope of PCI DSS 4.0 may be limited to checkout pages, but e-commerce merchants should be thinking broader than that. Understanding all the scripts on all the web applications across the entire site offers a better understanding of what an attack surface truly looks like. PCI DSS 4.0 is a strong signal to the industry, and merchants should use those requirements as a guiding force to advance security past what the new bare minimum will be.
About the author: Nick Merritt is the Vice President of Security OF Halo Security. Het is an elite penetration tester who leads product direction and penetration testing services for Halo Security. He brings more than 15 years of experience in application and network security testing to the company. He has been publicly credited for his contributions to responsible disclosure of zero-day vulnerabilities in mainstream software – including Microsoft. Prior to joining Halo Security, Merritt was an integral member at OneLogin and White Hat Security and served as Security Manager at McAfee.
