Firstly, if a site is PCI compliant, and new references to a 3rd-party file (e.g. image, Javascript, CSS, etc…) via http:// instead of https:// are added, does it violate PCI compliance?
Secondly, would adding a reference to a third party js library over https validate PCI compliance?
Thanks
(IANAQSA)
The PCI DSS only requires encryption to protect cardholder data:
Use strong cryptography and security protocols (for example, SSL/TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks.
Incidental page content which does not involve cardholder data does not require that level of protection. Of course, if your cart checkout (which must be secured as that's where card data gets entered) includes an unsecured http:// image, most browsers will complain, so you'll generally want to secure even the images and other content there.
If you're using a third party js library as a payment application, then PCI compliance is an issue - probably just making sure that it's PA-DSS compliant. However, if you're using a third party js to make your page look pretty, and it's not handling card data or impacting card data communication streams in any way, it won't impact compliance.
Updated to respond to @cchamberlain comment:
I believe that third-party libraries like Angular would fall under DSS (version 3.1 quoted here) section 6.2:
6.2 Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor supplied security patches. Install critical security patches within one month of release.
Contrast this to "bespoke or custom software developed by a third party" in section 6.3:
6.3 Develop internal and external software applications (including web-based administrative access to applications) securely, as follows:
- In accordance with PCI DSS (for example, secure authentication and logging)
- Based on industry standards and/or best practices.
- Incorporating information security throughout the software-development life cycle
Note: this applies to all software developed internally as well as bespoke or custom software developed by a third party.
So, if it's a software product for general distribution, it's assumed not to be malicious and you need to keep it up-to-date and react to security advisories. But if someone develops custom code for you, you have to treat it with equivalent levels of scrutiny to your own code.
I think this boils down to "trust that the owners of the library do not have ill intent" for something like Angular. You're still responsible if they do something inappropriate, of course.
The use of unprotected images on pages that demand cardholder data might or (more usually) might not endanger cardholder data, but you should expect an objection from the Guidance for requirement 4.1:
Generally, the web page URL should begin with "HTTPS" and/or the web browser display a padlock icon somewhere in the window of the browser.
Whether mixed-content warning UI breaks the letter of this guidance depends on the browser in question, but certainly it is against the spirit.
Having JavaScript hosted on HTTP for any page on the site is additionally genuinely dangerous as it would allow a MitM attacker to cross-site-script into the payment page. The same is true of CSS since on some browsers there are extensions that allow active scripting to be included in styles.
Having scripts/stylesheets hosted externally would come under “Use of Third-Party Service Providers”. There are hosting providers which maintain PCI certification for this purpose; general-purpose mirrors should be avoided. It is rarely worth the risk of bringing a third-party into contact with your cardholder data (which any JS on your site potentially is) just to avoid a few K of static hosting traffic.
