PCI DSS Qualified Security Assessors already face the immense task of being security experts on 397+ pages of dense content. To make matters worse, many merchants rush to find the lowest cost solution that will get them through the assessment. Pushing the boundaries of what the minimum acceptable approach is. While such solutions claim to tick all the boxes at first glance, many of them leave Card Holders glaringly exposed to client-side attacks. In some cases these solutions live in the gray area of vague wording but don’t actually meet compliance standards.
This guide helps QSAs identify these red flags. We wrote this from our own experience working with assessors, and the engineering evaluations we carried out while developing a PCI solution for our customers.
A Shorthand Checklist for QSAs:
To meet the requirements of 6.4.3 and 11.6.1 a merchant must be able to demonstrate (whether internally built or via a vendor):
- A mechanism to control the scripts on the page and ability to block them. CSP, SRI or a client-side script can achieve this. But a crawler alone can not.
- Script contents can be checked for indicators of malicious intent. For this to be possible, the solution must have the ability to show script content. No ability to show the script content = no ability to verify the script integrity. No evidence = no compliance.
- An inventory of all the scripts (inline, first-party, 3rd party and dependencies of the scripts) must be maintained with technical or business justification.
- Security headers of payment pages must be monitored and displayed at least weekly.
- A mechanism is in place to alert on the removal of any client-side security measures.
- Script contents must be monitored actively and alerted on changes.
A merchant’s solution would fail if it:
- Does not have a Client-side script or a CSP or an SRI that can block scripts from loading (fails to meet 6.4.3)
- Is purely a crawler without any level of code adjustment on the page (fails to meet 6.4.3).
- Only checks scripts URLs but does not monitor script contents (fails 11.6.1)
- Does not send alerts when security headers are removed or altered (fails 11.6.1)
- Does not track and display security headers at least weekly (fails 11.6.1)
Why these requirements exist:
Requirements 6.4.3 and 11.6.1 relate to client-side attacks. Attacks that execute in the application environment on the user's device but occur as a result of your dependencies as a merchant. This scope was added in PCI DSS v4. Card vendors have flagged that a significant amount of Card Holder Data (CHD) theft happens client-side, outside of the field of view of other security measures. A Web Application Firewall has no impact on client-side executions, especially those from 3rd parties. Therefore this scope increase was necessary. Many other compliance frameworks are following suit by expanding requirements relating to supply-chain security to include client-side executions.
Do PCI Requirements Apply to Single-page Applications (SPAs)?
The PCI DSS specification did not differentiate between single page web-application technologies or server side rendered web applications. This can cause confusion as some requirements may appear inapplicable or technically unachievable without monitoring the entire single page application, but the requested security actions do apply to single page applications. In many ways, SPA’s have significantly contributed to the need for stricter security requirements by increasing the amount of code that executes on the client-side.
Scope of 6.4.3 & 11.6.1:
The PCI specification states that “This requirement applies to all scripts loaded from the entity’s environment and scripts loaded from third and fourth parties”. Therefore, any mention of ‘script’ includes same origin (1st party) scripts, 3rd parties and subrequests of said 3rd parties.
Many traditional tools do not monitor client-side scripts from the same origin or scripts that are injected inline. In other words, these tools don’t monitor first-party scripts or the snippets of code dropped directly onto the page (e.g. analytics tags). This is a problem, as client-side attacks have frequently originated through scripts from the same origin.
6.4.3:
The requirement states:
“All payment page scripts that are loaded and executed in the consumer’s browser are managed as follows:”
1. “A method is implemented to confirm that each script is authorized.”
This means that any unauthorized scripts must be stopped from being served. There are only 2 ways to do this:
- Implementing script CSP or SRIs: Make sure that the Content Security Policies (CSP) are strict and in blocking mode. By design CSP is a mechanism to trust sources, not the actual scripts themselves. These are fundamentally different things. If a trusted source is infiltrated, malicious scripts can pass right through without any security measure.
Subresource integrity (SRI) does operate on the script level and validates the actual payload. However, SRI is not always a practical option for dynamic scripts that change frequently on the client side.
- Using a client-side script: A client-side script that loads before all other scripts can adjust or unmount scripts. It can prevent unauthorized scripts from executing partially or in full.
If a merchant doesn’t have CSP, SRI, or a client-side script on a page to prevent unauthorized scripts from loading. 6.4.3 is not met.
Important: a crawler based solution without CSP does not meet PCI requirements.There are a number of vendors out there offering crawlers that do not meet this requirement.
2. “A method is implemented to assure the integrity of each script.”
This means that each script has to be monitored. In 11.6.1 it is further explained that this includes the script contents. Therefore, a security solution that meets 6.4.3 and 11.6.1 must be able to show the script contents that were served to the user.
Where the solution runs matters: Solutions that run externally can not guarantee that the script they reviewed is what is actually served to end users. Bad actors are known to identify the cloud provider IP addresses of crawlers and exclude malicious scripts from being served to them. Therefore, it is unclear whether the requirement can be met by any solution that does not live in the application at runtime.CSP alone can not verify the script integrity as it does not inspect the script content. SRI however does validate the script contents against a hash.
Script URLs + Threat Feeds: Some solutions claim compliance by checking script URLs against threat feeds, but that only verifies the file name and not the contents. Since 11.6.1 specifically requires monitoring the actual script payload, these approaches fall short of compliance. It’s the same reason an anti-virus software doesn’t stop at file names, it inspects what’s inside.
As a general rule of thumb: if a solution does not show the script contents, it does not meet integrity monitoring requirements.
Validation Test: In order to understand whether a solution can verify script integrity it is recommended to run a test by implementing an example ‘malicious’ script on a staging environment.
3. “An inventory of all scripts is maintained with written business or technical justification as to why each is necessary.“
Merchants may use spreadsheets or dashboards provided by vendors to meet this requirement. AI is often used to write the justifications.Some solutions do not offer this natively, at this point a spreadsheet can be used. However, it is important that this spreadsheet is up to date. A google tag manager dashboard export does not suffice as the application itself may have client-side scripts injected outside of google tag manager.
Outdated or incomplete inventories: It is advised that a QSA checks the solution in question to verify that all scripts are in the inventory and that the inventory is up to date.
11.6.1
A change- and tamper-detection mechanism is deployed as follows:
1. “To alert personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) to the security-impacting HTTP headers and the script contents of payment pages as received by the consumer browser.”
This requirement relates to monitoring all server-side security headers that can be adjusted in the timeframe leading up to an attack but also the requirement to monitor the script payloads.
The script payload must be analysed and timely alerts must be sent in case of a compromise. Of course, an alert without indicators of why the alert was sent is pointless so in order to be actionable the script contents should be stored and displayed for forensics.
Examples of changes that require alerts: “E-commerce skimming code or techniques cannot be added to payment pages as received by the consumer browser without a timely alert being generated. Anti-skimming measures cannot be removed from payment pages without a prompt alert being generated.”
It is also necessary to have a mechanism in place to monitor any tampering to the security solution itself. If it is removed, this should result in an alert.
To meet these requirements the list of security headers below must be monitored:
| Security Header | Description |
|---|---|
| Content Security Policy | Also known as CSP header. |
| Content Security Policy Report Only | The CSP header but in reporting only mode, none blocking. |
| Report To | Reporting endpoint following the legacy specification. |
| Reporting Endpoints | Alternative reporting endpoint following the more recent specification. |
| Strict Transport Security (HSTS) | Restricts the browser to only connect over HTTPS. |
| X-Frame-Options | Allows to define whether iframes' are allowed to be injected into the webpage. |
| Cross-Origin Resource Policy (CORP) | Allows the webpage to define which resources may be loaded and from where. Related to CORS and Same-Origin Policy. |
| Cross-Origin Opener Policy | Allows the webpage to define how the browser should interact with different context such as tabs, iframes and windows. |
| Cross-Origin Embedder Policy | Allows you to control which cross origin components the browser can load. |
| Permissions Policy | Allows to define which device APIs are allowed to be accessed by the web applications and its dependencies. |
| X-Content-Type-Options | Strictly forces the browser to check the content types. Browsers could otherwise allow malicious injections through unintended content types. A very common method used in client-side executions and MIME style attacks. |
| X-Permitted-Cross-Domain-Policies | Is a more legacy security header outlining which domains flash player and PDF readers were allowed to fetch content from. |
| Referrer Policy | Fun fact: there is a typo in the HTTP spec for 'referer'. This header allows to define how much information is sent along by the referrer, previous page or parent page. |
| X-XSS-Protection | Is a legacy security header to enable to disable the browser native XSS detection features. |
2. “The mechanism is configured to evaluate the received HTTP headers and payment pages”
This echoes the points mentioned above of monitoring all the HTTP security impacting headers on the payment page.
3. “The mechanism functions are performed as follows: At least weekly OR Periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1).”
This section indicates that these checks must happen at least weekly or the timeframe mandated by 12.3.1. Sampling can be allowed on the subject of HTTP headers and script contents, but at least weekly these must be reviewed. A week is a long time, it is recommended to advise merchants towards a more proactive security perspective.
AOC’s and ROC’s for Vendors
Vendors that provide security solutions for 6.4.3 and 11.6.1 are not TPSP in the context of payments (Third-Party Service Provider) and do not require any level of SAQ, AOC or ROC on their own product by a QSA. Some larger vendors do hold these certifications for other parts of their business, and sometimes they list their PCI related tools inside those reports. That doesn’t inherently mean those tools have been tested or validated. The merchant is still ultimately responsible for proving compliance with PCI DSS. Some vendors pay QSAs to review their solutions and publish whitepapers, but even this does not entirely guarantee compliance for individual merchants.
FAQ & Glossary
Server side rendered web applications v.s. single-page applications:
Traditional server-rendered apps load a new page from the server every time you click an element. For example: An online banking portal where each click (e.g. checking balances) reloads a full new page from the bank’s servers.
Single-page applications (SPAs) on the other hand, load once and rely on JavaScript to update content dynamically. For example: An e-commerce checkout built in React where the page never fully reloads; instead, forms, product details, and payment fields update dynamically in the browser. There has been a rise of Single-page applications as more websites are built with web development frameworks like React, Angular, and Vue.