PCI DSS - let's be pragmatic about JavaScript Client Side Encryption and SAQs

Tags: #<Tag:0x00007f332a71bd08> #<Tag:0x00007f332a71bbc8> #<Tag:0x00007f332a71ba88>


SAQ A-EP because of JavaScript forms?

It’s this time of the year: PCI audits. Web apps mature, payment methods evolve, and so does PCI DSS.

There was a time, when I used this document by Visa to explain the implications of different payment workflow integrations; among them

  • JavaScript based form submission
  • iFrame based forms, that get loaded from a Service Provider entirely
  • iFrame based redirects, which open a site that gets loaded from a Service Provider entirely
  • and last but not least DirectPost

But what if someone uses a Public Key based Client Side Encryption (CSE) scheme with JavaScript, that guarantees that the Merchant does not have the Private Key? What if if the browsers evolve and the JavaScript is being used to encrypt credit card data? An approach like that is not mentioned in the document from Visa.

Many QSAs would put this into a SAQ A-EP, simply because it’s possible and it means business.

Reality meets PCI DSS

In reality the JavaScript CSE solution might provide a higher confidentiality than an iFrame. The credit card data is not only encrypted via TLS >= 1.1 (in June 2018 TLS 1.0 must be turned off). It’s also encrypted with CSE in the customer’s browser. - Two layers of encryption.

The encrypted data (from the CSE process) usually gets sent to the Acquirer / Payment Service Provider via an API, that is hosted by the Merchant.
These API calls submit the encrypted credit card data. In theory it is also true, that encrypted data can be in scope of PCI DSS, and that it’s possible that an entity is not eligible for an SAQ A (ROC), simply because of that.

But it’s also possible to do an SAQ A (ROC).

It is possible that encrypted data may potentially be out of scope for a particular entity if, and only if, it is validated (for example, by a QSA or ISA) that the entity in possession of the encrypted data does not have access to the cleartext cardholder data or the encryption process, nor do they have the ability to decrypt the encrypted data.

What does that mean?

This means that you can seek out a accredited professional to review your Payment Service Provider and your integration in order to determine your eligibility for an SAQ A or SAQ A-EP (ROC). Most ISAs / QSAs are well aware, that Merchants in general do not want to do an SAQ A-EP.

In case of a JavaScript CSE solution, relevant security controls may include:

  • verify that the JavaScript from the PSP is unmodified
  • ensure that there is a valid SSL certificate in place
  • ensure that no credit card data can get submitted when JavaScript is deactivated in the browser
  • assess the hosts within the Merchant’s (small) CDE and search for credit-cards
  • confirm that the CSE is PCI compliant (PSP has to account for that)
  • collect the AoCs from the SPs, colocation sites and Acquirers

If we do PCI assessments, and we are not pragmatic about JavaScript, we need to remind ourselves that pervasive compliance is not a good business model and that this is not the intention of PCI DSS.

PCI DSS compliance is only a contractual obligation, that exists via the Merchant agreement. It’s not a law. In reality more than 50% of the Merchants are not compliant. These entities could never implement the controls of an SAQ A-EP. And with a sane PSP, that uses JavaScript CSE this might not even be the right thing to do for them.

Do Payment Service Providers lie about PCI eligibility criteria?

Payment Service Providers and Acquirers can lie. They are not responsible for the compliance of a Merchant entity. They can request an appropriate compliance level from the Merchants they are in business with. Usually it’s not in their interest to enforce PCI DSS.

For the QSA / ISA it is important to know, that the PCI SSC has a QA program. The SAQs or ROCs can get selected for a review. For the respective Merchant it is important to know, that the PCI SSC might flag a report. This can lead to a suspension of the Merchant’s eligibility to process credit cards.

It is in the interest of the Merchant to support the assessor, and to review the evidence sheet. - And to ensure that the evidence sheet contains the relevant policies and procedures, including areas such as the ERP (where the Acquirer reports might go to), Customer Support portals, CRMs, Ticket Systems, PBXs and so on.

Yes, Sensei...

A Service Provider does not determine the eligibility criteria for Merchant entities, and does not determine whether they have to do an SAQ A or A-EP. Especially if the Merchant gets breached, they will insist that they only issued basic recommendations, that were not specifically for the breached entity.

So unless the entity went through a QSA / ISA assessment, there is a higher residual compliance risk.


The confusion PCI DSS (3.2) creates among Merchants (related to JavaScript, iFrames, DirectPost) can get resolved. It’s important to pay close attention to the details of the payment workflows.

Minding these details is the job of the assessor. The decision is with the assessor, but the reasoning should be sane. Solely relying on a 4 years old document from Visa is not appropriate for a yearly assessment in 2018.

The fact that JavaScript is being used is not enough to determine whether a Merchant has to meet the SAQ A-EP requirements. In the same sense an iFrame solution does not guarantee that an SAQ A is enough.


26.02.2018 - published
27.02.2018 - clarifications added