After the PCI SSC dropped the revised SAQ-A at the end of January 2025, a FAQ (1588) has been issued to clarify how to meet the new eligibility criteria in lieu of some controls being removed from scope.
A quick refresher on the changes …
“The merchant has confirmed that their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce” system(s).”
This replaced requirements 6.4.3 and 11.6.1 which covered the monitoring of JavaScripts and security headers, the underlying ethos being to mitigate the MageCart attack vector. It also removes the requirement to monitor the security headers.
The abridged version of FAQ 1588 is as follows:
- If the merchant is using the Full Redirect mechanism, it does not apply.
- For merchants using the iFrame mechanism:
- Look to the guidance in requirements 6.4.3 and 11.6.1 to protect the web page doing the handoff to the payment gateway.
- Get confirmation form the payment gateway provider that their solution includes mitigation for such attacks.
Many merchants don’t like the full redirect mechanism in terms of look and feel, payment flow and similar aesthetic reasons.
The iFrame can be styled into the checkout page, but comes with some baggage that requires a protection mechanism some of which can be quite expensive.
From the guidance on PCI DSS requirement 6.4.3, use of the Content Security Policy “CSP” HTTP header is an acceptable mitigation to control both the source of the iFrame and where JavaScripts can be loaded from. In addition to controlling the source URL of the JavaScripts, a nonce value can be added to script elements within the CSP to further control which JavaScripts are permitted. Embedded scripts can also be controlled using a hash value added to the CSP.
Use of the CSP is our preferred solution as it requires no capital expenditure to implement. Only effort to add the header to the website and test it. Implementation of the CSP is considered general best practice along with many other security headers. These headers are usually brought up on penetration and web application test reports if they are missing or not tight enough.
It should be noted that incorrect use of the CSP can cause problems with the website. Any mis-configuration will result in elements being prohibited from loading by the consumer’s browser, so ensure things are tested fully before implementing in live.
At this point, Content Security Policy Level 2 (2016) is the current version usually implemented within web browsers. CSP3 is currently in draft with the W3C.
