It turns out that how you implement e-commerce can have a huge impact on your compliance footprint (i.e., the number of PCI security controls assessed depend on your implementation decisions). Understanding how your e-commerce implementation fits into PCI can save you time, effort, and money when implementing, monitoring, and maintaining these base-line controls. Not understanding your e-commerce PCI can be frustrating, painful, and expensive. Beyond PCI's minimum controls, you will need to consider residual fraud and security controls.
Welcome to our multi-part series of articles on e-commerce security and compliance. In this article, we look at the current PCI DSS v3.2.1 compliance framework for shopping carts and payment pages. We explain PCI's e-commerce framework, the difference between shopping carts where the payment page is managed by the merchant or managed by a PCI compliant third-party, as well as the different compliance footprints and burden of both.
In future articles we will look at the security implications of JavaScript, and "MageCart" e-commerce skimming attacks.
Note: This article was originally published on 2021-06-10 and has been updated to better align with the rest of the series.
E-commerce transactions typically process cardholder data (i.e., PAN & Expiry Date) and sensitive authentication data (e.g., the printed Card Security Verification Number). Additional fraud and security controls such as Address Verification Service (AVS) and 3 Domain Secure (3DS) may apply. These measures attempt to provide merchants with additional fraud prevention control while minimizing user friction.
There four scenarios for implementing merchant e-commerce websites within PCI DSS. Each scenario has a different "compliance footprint" (i.e., set of applicable requirements). Each scenario is described below:
The distinction between a merchant website using a Direct Post Form or an IFRAME (i.e., Scenarios #2 vs #3) is frequently misunderstood and often creates confusion among merchants and service providers. This leads to bad advice and non-compliant implementations. A merchant implementing their e-commerce site believing they are eligible to use the smallest compliance footprint (Scenario#3) but actually implementing Scenario#2 will find themselves non-compliant, needing significant remediation, or worse - the subject of a data breach investigation. The remainder of this article looks at Scenarios #2 and #3 in detail.
The critical guidance supporting this distinction is captured in PCI FAQ’s 1438 and 1292 (paragraphs 2, 3, and 5 can be challenging to unpack). However, the basic rationale for the distinction comes down to what happens inside the Document Object Model (DOM) of the user's browser:
Or put another way, hosting the data collection form in the DOM of the merchant shopping cart means that the third-party processor cannot properly control the collection of cardholder data. This makes the data more easily accessible to web-replay and analytics providers as well as to criminals looking to steal valuable data.
The distinguishing factor between these two scenarios hinges on the technical details of the implementation. Specifically, which DOM collects the cardholder and sensitive authentication data for the payment page. It turns out that what is rendered is more important than how it's rendered. It makes no difference if the HTML elements are hardcoded into the shopping cart or built on the fly. A scripted IFRAME is still a small 27 requirement compliance footprint, and a scripted form is still a large 213 requirement compliance footprint.
This diagram shows Scenario#2 implementing a direct post payment page:
Note: The dashed line indicates a logical flow which can be implemented via call backs, encrypted responses, or session tokens.
This diagram shows Scenario#3 implementing redirection:
We are nearly at the end of our compliance journey, but not the security journey:
If you've successfully minimized your compliance footprint, you should be able to focus some of the resources you saved on controlling risks to your bottom line and other risks of your choosing.
Some merchants and vendors will argue that DIV's provide protection. They do not. DIVs (division/section separators) are containers for organizing elements in the browser, applying styles, or manipulating the DOM with JavaScript. DIVs are just a distraction in security and compliance discussions. FAQ #1292 includes "Merchants and QSAs receive often conflicting advice from vendors which can be especially confusing when the difference between using an IFRAME and embedding a payment form in a <DIV> appears to be minimal. However, the difference in security is substantial: ..."
Even if you can achieve the smallest shopping cart footprint, Scenario #3, you need to make sure that you cover all of that functionality. Many organizations split functionality across multiple on-premise systems, or outsource parts of their web content hosting across one or more providers. The controls, e.g., unique user IDs, need to be applied on all applicable systems (e.g., Magento, WordPress, GitHub, Amazon AWS, Azure, Akamai, Google GCP, GoDaddy, etc.). Additionally, don't overlook security impacting systems such as code repositories (e.g., GitHub, GitLab, Bitbucket, CodeCommit, etc.).
Outsourcing does not eliminate your PCI DSS responsibilities if you have a merchant account. Even if everything is fully outsourced and hosted by a third-party, you are still responsible to comply with requirement 12.8 to ensure your provider is compliant. Failure to apply due diligence or understand any PCI responsibilities not covered by your provider means you've dropped the ball on PCI. Before you build it and sign contracts, make sure you understand what your service providers do for you and what they do not.
Review your service provider's PCI DSS responsibility matrix. This document details which PCI DSS responsibilities are on them, which are shared, and which are on you. Don't assume your provider does everything. Compliant services vary dramatically depending on the nature of the business offering. Cloud Infrastructure providers, like AWS and Azure, are compliant for infrastructure but won't cover your application as that isn't part of their service. More focused platform service providers, like Salesforce, may do more for you but often push requirements for customizations back on the merchant. Some highly focused shopping cart providers may cover more, even most, PCI responsibilities. But whatever they don't cover, you will have to. Either on your own or with additional service providers to cover things like application development and maintenance. Getting this right is critical to achieving business, compliance, and security goals.
You will want to be certain you understand which footprint applies to your implementation. Getting it wrong will mean you've potentially ignored up to 300+ PCI DSS requirements that apply to you. Discovering this mid-audit will be an unpleasant experience that will almost certainly result in a non-compliant assessment, significant remediation efforts, delays, and broken budgets.
We have long expected the PCI council will change the PCI-DSS guidance and possibly add new requirements. Here are some of the reasons we expect the guidance on shopping carts and payment pages will change:
Merchants implementing their own e-commerce shopping carts using third party payment processors need to understand the security and compliance implications of their design choices. Scenario#2, merchant managed payment pages, have a large compliance footprint that comes with a significant cost. Scenario#3, outsourced payment pages, have a significantly smaller compliance footprint that reduces risk and has a lower cost. The difference between the two hinges on seemingly small technical details of the implementation. Specifically, in use-cases where both send cardholder and sensitive authentication data to a compliant third-party the difference will be determined by which browser DOM collects that data. While these aren't the only ways to achieve e-commerce compliance, they are the most common. Organizations that understand the compliance rules around e-commerce will be better prepared for success.
This concludes are look at e-commerce shopping cart compliance under PCI DSS 3.2.1. In our next articles we will examine (a) the trends in e-commerce skimming attacks and payment breaches, and (b) 3rd-party supply chain risks due to JavaScript risks not well addressed by current PCI guidance.
PCI compliance footprints can be used to simplify compliance for both large merchants completing Reports on Compliance and small merchants completing Self-Assessment Questionnaires (SAQs):
PCI FAQs on Shopping Carts and Payment Pages:
PCI DSS v4.0 news:
HTML Tags
Original Publication: 2021-08-05
Updated PCI FAQ & Learn More links: 2023-06-16
David Gamey : Dec 7, 2017 10:07:00 PM
PCI DSS is all about scope. Getting scope right or wrong is perhaps the single most critical factor determining the ultimate success or failure of...
David Gamey : Nov 1, 2021 10:07:00 PM
PCI DSS can be hard and not preparing for it just makes things harder. Following this advice is guaranteed to make it both more exciting and painful.
5 min read
CG Blogger : Jan 10, 2018 10:07:00 PM
PCI DSS v3.2 is due for an update this year - but what will that look like? In this article, we peer into our crystal ball to make some predictions...
David Gamey