Although variants of this question have been asked before, they seem to be about general risk, and I'm interested in the PCI DSS connotations.

If an e-commerce site is looking for level 1 or level 2 PCI DSS compliance (and therefore needs to involve a QSA as part of the SAQ review or ROC full audit) and the marketing department are asking for third party analytics javascript tags to be inserted onto every page, will this necessarily make PCI compliance almost impossible to achieve?

The risk appears to be that if the third party (for example Google Analytics, but there are many others) 'need' to embed a javascript line into every page, including sensitive checkout or login pages, etc. and that javascript pulls more code from the third party's servers beyond your full control, then you have essentially extended your PCI boundary to include that third party - and giving the PCI DSS auditor access to their servers and processes is going to be almost impossible in any meaningful way.

In essence, you would have to completely take on trust the effectiveness of the third party tracking code, and all the security controls and testing etc. surrounding their code changes because you have little or no control over the script(s) that are pulled in to your website. If I were QSA-ing this solution I'd raise some serious doubts about this approach.

So does this mean that PCI DSS compliant e-commerce web sites can't have active third party tracking javascript embedded onto all pages, or is there some flexibility here?

  • I think the issue is the JS file can change outside of your control. You can use some trackers without JS files (including google analytics), which may get you around the problem. Obviously I'm not a QSA, if you have one you could always ask them for clarification.
    – Jay
    Oct 27, 2015 at 12:46
  • Not directly responsive to your question, but a very relevant & interesting side issue: attackers in the wild have used Google Analytics tracking code on credit/debit card info entry pages to exfiltrate card data: trustwave.com/Resources/SpiderLabs-Blog/… Modification to the code of your web payment app is still required to add code that will actually steal card info on the page and encode it for the Analytics as trackable info, but GA will then happily store it at whatever merchant id you choose. Oct 27, 2015 at 21:30

4 Answers 4


There is no specific PCI requirement about having 3rd party Javascript on your site or not.

Personally, I would not consider an analytics provider to be a PCI Service Provider under PCI DSS.

There are requirements however for your custom website to be securely developed (6.5), and for it to reviewed via security assessments or to be run under the protection of a WAF (6.6).

Additionally there are requirements for vulnerability scans (11.2) and external penetration testing (11.3.1).

A third party library hosting your website should be flagged as a vulnerability under one of these requirements. During a normal, non PCI security test, this would usually be worded that there is a third party library present and this risk should be reviewed to ensure that the library is trusted, and the domain it is hosted on is also trusted, should this is an external domain. If the third party domain is untrusted, or if it is compromised then it would be a risk to your environment and to your PCI compliance. That is, something hosted on google.com would probably be OK, but something hosted elsewhere may not.

During a security test, this is usually initially ranked by a pentester as a low risk vulnerability. However, it should be reviewed by the business. If your business accepts this risk, then simply document it as such. If you consider it a risk that cannot be accepted, then you should document the steps taken to mitigate such a risk. For example by putting the third party script through a code review, and then hosting the script locally rather than this being fetched from a third party domain. Also, browser subresource integrity is now widely supported, in which the browser rejects remote scripts should they be altered: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity

PCI DSS is mostly about documenting how you have dealt with the spirit of each requirement, rather than a black or white list of cans and cannots. Then, should you be audited you can take the QSA through your business decision process to demonstrate how you are meeting the requirements above.

Disclaimer: I'm not a QSA, nor, more importantly, your QSA. Only your qualified QSA can accurately assess your responsibilities under PCI DSS, as they will have full knowledge of your business and how it relates to your card processing activities.

  • That's very interesting, but if the requirement 6.5 is for secure development, how could you show this to be the case with third party code - especially as it can be changed 'on a whim' by the code's owner (though that sounds emotive!)? When you say the risk of compromise of a third party's domain is considered to be 'low', on what basis? Is there some passive acceptance of analytics providers somehow being relatively safe from compromise? Sorry to be specific, and I know the QSA will answer, but these are relevant points now (to me...) Oct 27, 2015 at 14:49
  • Well the security assessment will usually rank it as a low risk vulnerability - your business, having been alerted to the risk may well review it and re rank it. For example, if the third party library is hosted on google.com then it would probably remain low, however if it is on bobswidgets.example.com then it may be a different story. 6.5 relates to your own custom development - i.e. including a third party library on a separate domain or including it locally (or not) is totally under the control of your development process. Oct 27, 2015 at 14:54
  • I believe the sections of PCI-DSS that you reference (6.5, possibly 6.5, 11.2, 11.3.1) are the basis for asserting that the third-party code and servers would be in-scope, which is the basis for the rest of the problem. Oct 27, 2015 at 18:52
  • I'd include reference to file integrity requirements within requirement 11.5 of the PCI DSS and monitoring of system, configuration and content files. The web applications files should be in scope for this and should be static. If changes are made, there should be alerts and these should be investigated. Certainly there should not be alterable code by third parties on pages handling authentication or other sensitive data.
    – AndyMac
    Oct 27, 2015 at 20:07

I am not a QSA. You should consult your QSA on this matter.

I entirely agree that delivering javascript from an unsecured source as part of pages containing data in scope for PCI-DSS should not pass muster with an alert QSA. I would go a step further and say that other pages in the same session should not contain unsecured javascripts.

I may be overly conservative, but I would go a couple of steps further than that. Performing server or client side includes of any content would not pass muster were I the assessor. Consider that this source outside you control can change the content without your knowing they have done so. What mechanism do you propose to apply to test the safety of that outside content? A wide and ugly range of potential attacks occur to me. How reliably can you assure that it is safe each time it is included?

As an alternative, consider copying the content to your own server, vetting it security, then serving it up directly, without dynamically loading it from the third-party. In effect, this makes it part of your site and subject to your change control processes.


PCI DSS 3.1 Requirement #12.8 states

"Are policies and procedures maintained and implemented to manage service providers with whom cardholder data is shared, or that could affect the security of cardholder data ..."

When examining whether or not analytics falls within scope, consider the following points:

  • Analytics providers are definitely providing a service, and should therefore be considered service providers. The PCI Compliance Guide further reinforces this, taking as reference the PCI Service Provider definition:

"Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data. This also includes companies that provide services that control or could impact the security of cardholder data. (Source:www.pcisecuritystandards.org)"

  • External javascript definitely has the potential to affect the security of your PCI data. (See JaimeCastells's answer)

If you are required to have a QSA review the requirement, then use their opinion. If your PCI level does not require a QSA, you need to make the decision based on your best understanding after thoroughly researching the question (and optionally hiring a consultant QSA).


The main concern is that you have to trust Google or any other third party which helps you to track the users. When you lay out PCI DSS in a strict way you are responsible to make sure that only PCI DSS compliant entities may get access to card holder data or any sensitive data. So loading a script from a third party which is not compliant is not allowed. The compliance has to be proven by an AOC.

However what you can do typically is hosting the tracking script on your server. Which means you can assess once that the corresponding script is not stealing card data. When you host the script you have the control and you do not need to have an AOC. Typically the actual tracking data is passed over to the third party by an image. So when controlling the script you control what data leaves your environment and as such you get compliant.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .