Comply with PCI DSS 6.4.3 and 11.6.1 for "free"

PCI DSS 6.4.3 and 11.6.1 are client-side concerns, and most organizations have never had to deal with them at this level of scrutiny before.

So, can you comply with both requirements without a paid solution?
The answer is: Yes, sort of. But it's practically impossible.

This important sentence should be in the back of your head while reading throughout this article. It was added in the January update pertaining to req. 6.4.3 and 11.6.1.

“For merchants to qualify for SAQ A, they must confirm their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s)”. 

Why these requirements were set

Since JavaScript was added to browsers in 2011, client-side execution has opened the door to widespread card skimming attacks. Sophisticated actors now inject malicious scripts via dependencies, plugins, or supply chain compromises. Most often, they exfiltrate payment data dynamically, often targeting only a small percentage of users to stay under the radar.

Visa, Mastercard, and Amex have all pointed to client-side script-based attacks as the leading source of credit card data theft. Tokenization helps, but only to a degree. If the client is hijacked, the attack still succeeds.

So PCI DSS v4.0 rightly mandates that businesses implement controls to:

• Prevent unauthorized scripts from executing (6.4.3)
• Assure the integrity of scripts (6.4.3)
• Maintain an up-to-date inventory of scripts with business justifications (6.4.3)
• Detect tampering or unauthorized modifications to payment pages (11.6.1)

How to Be Compliant Without Buying a Solution

If you're resourceful, technically capable, and willing to maintain the tooling yourself, here’s how you can do it.

1. Prevent Unauthorized Scripts (6.4.3)

To meet the requirement to ensure only authorized scripts are allowed to load and execute, you need a strong enforcement layer. A Content Security Policy (CSP) can serve this purpose, but it must be configured tightly and maintained actively.

What you can do:

• Deploy a strict CSP header using script-src to whitelist allowed domains.
• Use nonces or hashes to explicitly allow inline or dynamic scripts.
• Regularly audit your policy and update it with any script changes.
  
  

Is it enough for PCI?
Yes, BUT only in formal terms.

Dynamic scripts can NOT be fully protected against with CSP.

CSP is recognized as a valid control for authorizing scripts. However, CSP alone doesn’t track intent. You need supporting documentation that proves why each allowed source was authorized.

BUT, remember the sentence from above:

“For merchants to qualify for SAQ A, they must confirm their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s)”.

Does CSP solve this with this context? NO. Should a source stay the same, but the contents of the delivered script changes, a CSP would NOT catch it.

The 2024 Polyfill attack would NOT be stopped by a CSP. This technically means your site IS susceptible to attacks, hence you need a security tool to fully comply. You can sign up or book a demo to chat with us.

Summary bullets:

• Use CSP with script-src restrictions and nonces/hashes.
• CSP must be updated and audited regularly.
• CSP is brittle and can break apps; manage with care.

2. Verify Script Integrity (6.4.3)

You’re expected to detect when a script has been tampered with. For static scripts, Subresource Integrity (SRI) is a standard solution. It checks that only scripts with the expected hash load successfully.

What you can do:

• Add integrity and crossorigin attributes to every third-party <script> tag.
• Periodically fetch scripts, hash them, and compare to known-good hashes.
  
  

Is it enough for PCI?
Yes, BUT only for static scripts.

Dynamic script can NOT be covered with SRI alone.

Dynamic scripts (e.g. analytics tools, A/B test runners) often change with every request and will break SRI. PCI expects you to acknowledge and mitigate this limitation, either by avoiding dynamic scripts or implementing a way of monitoring.

How to monitor those? That is not possible without tooling. Either a paid solution (like us here at c/side 👋) - or your own built solution.

Without going into depth, here is how you could build your own monitoring tool:

1. Create a list of dynamic script URLs
2. Fetch the script contents
3. Normalize the payload
   1. Strip timestamps, cache-busters, or CDN tracking headers (if necessary).
   2. Save a cleaned version of the content for comparison.
4. Hash or diff the result
   1. If changed: log and alert.
5. Alert on unexpected changes
   1. Send an email for example
6. Document your process
   1. PCI wants evidence that you're actively monitoring script integrity.
   2. Keep logs of these checks and any resulting actions.

However, is this practically possible?

Would you build you own anti-virus software for example? We'd argue the answer for most of us is a clear "no". Building an engine to flag malicious behaviors in JS is a tough thing to do and will require a substantial dataset to be successful. This is more than just a time spent cost issue. It is also a resources issue.

Summary bullets:

• SRI works only for static scripts. Use it where possible.
• SRI Does NOT work with scripts that have varying payloads.
• Monitor actual script content is needed via tooling.

3. Maintain a Script Inventory (6.4.3)

You’re expected to maintain an inventory of all scripts that run on the payment page. This means both static and dynamic scripts, as well as inline scripts, third-party sources (like tag managers or analytics), and anything loaded via frameworks (like React or Vue). PCI wants to see that every script has been reviewed, approved, and has a business or technical justification. This every 7 days (weekly basis).

What you can do:

• Create a version-controlled list (spreadsheet or YAML/JSON file).
• Include: script source, expected hash (if static), business/technical justification, owner/team.
• Update it with every deployment or code change (not script code changes). affecting the payment page.

Here's what you need to include:

• The source or URL
• Whether it's static or dynamic
• A hash (if static and SRI is used)
• Business/technical justification
• Owner or responsible team
• Notes on monitoring (especially for dynamic scripts)
  
  

Is it enough for PCI?
Yes, PCI doesn't require anything else here.

A manual list is acceptable as long as it’s accurate and maintained. Dynamic scripts still need to be listed, even though you can’t hash them. In those cases, PCI expects you to explain why SRI can’t be used and how the script is being monitored instead.

NOTE: This does NOT mean you can just make an inventory and not take action on the points above. It is a slightly looser described requirement that some see as the silver bullet. It is not.

4. Tamper and Change Detection (11.6.1)

PCI wants you to detect unauthorized changes to the payment page as received in the user’s browser. This includes changes to content and HTTP headers (like CSP, CORS, etc.).

What you can do:

• Use a headless browser (e.g. Puppeteer) or curl to fetch the live payment page. You will need to spend money on that...
• Capture headers and HTML content.
• Compare with a known-good baseline and alert on changes.
• Normalize output if needed to avoid false positives (especially important for dynamic content).
• Document what changes trigger alerts, who responds, and how.
  
  

Is it enough for PCI?
Yes, ASSUMING you run it regularly and have documented what changes trigger alerts, who is notified, and what your response plan is.
The required cadence is weekly, UNLESS otherwise justified by a risk analysis.

Note on dynamic pages: Client-rendered frameworks (React, Vue, etc.) often load or mutate the DOM after page load. If you don’t account for this, your monitoring will flag false positives.
For PCI, this is arguably fine. AS LONG AS you clearly define what you do check (e.g., CSP header, external script domains, key DOM selectors) and why.

Should you still suffer from an attack, keep in mind the important sentence: "For merchants to qualify for SAQ A, they must confirm their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s)”.

Summary bullets:

• Use curl or headless browser to capture and diff headers and HTML.
• Normalize dynamic content to reduce false positives.
• Run checks weekly (or more frequently based on risk).
• Set up alerting and a documented response process.

So, can you do it for "free"?

Yes, sort of. But it's practically impossible.

It’s technically possible, but practically AND compatibility fragile. Most importantly, you will more than likely spend more money, time and resources than opting for a paid solution.

You’d need to:

• Write your own tools or scripts
• Build your own method to analyse scripts - this is costly and as a non-security company you would likely not have access to the data or competences to do this. Would you build your own anti-virus?
• Monitor script integrity manually
• Maintain a script inventory with discipline
• Normalize and compare dynamic pages without drowning in false positives
  
  

And most importantly:
You need to prove that your site is not susceptible to client-side attacks, as explicitly required in the January PCI DSS update.

A CSP won’t stop supply chain attacks.
An SRI is not compatible with dynamic scripts.
And a basic curl check won’t protect against context-aware, selective exfiltration.

If you're going the DIY route: Document everything, automate where you can, and prepare for overhead. And, build your own tooling, if possible. But most importantly calculate your time and resources (human or otherwise) and run the numbers. The chances are, you'd likely be better suited to go for a paid solution.

If you're looking to be completely compliant and be safe, we built c/side for exactly that. You can book a demo here or sign up to be compliant today.