The Payment Card Industry Data Security Standard (PCI DSS) is a set of guidelines that ensures the safety of card transactions globally. Created by the PCI Security Standards Council, its goal is to protect against data theft and fraud in debit and credit card transactions.

PCI DSS 4.0.1 applies to all entities that store, process, or transmit cardholder data (CHD) and/or sensitive authentication data (SAD), or could impact the security of the cardholder data environment (CDE). This includes all payment card account processing entities such as merchants, processors, acquirers, issuers, and other service providers. Insurance providers also consistently look at regulations like PCI DSS. Not complying might result in higher rates.

A new addition to 4.0.1 is the monitoring and management of 3rd-party JavaScript. Both tackled requirements 6.4.3 (page 153) and 11.6.1 (page 288).

Requirement 6.4.3

Requirement 6.4.3 mandates any website that takes digital payments, to authorize each script on payment pages, maintain an inventory of all scripts, and ensure their integrity.

How you go about that, is left mostly in the open. Maintaining an inventory and writing a justification is fairly easy to do manually. Assuring their integrity and authorization, is a bit more of a grey area.

With c/side you can see all the scripts on a domain, and keep track of the changes on each script.

c/side keeps an inventory on all pages (including payment pages on your domain), and shows you the payload of the script on each request. This allows you to see code changes, updates and potentially malicious action.

While not required by PCI DSS 4.0.1, we also block and alert you on (malicious) changes.

All of this fills that grey area, and allows your business to both assure the script’s integrity and authorization.

Requirement 11.6.1

• Alert personnel to unauthorized changes to HTTP headers and payment page scripts
• Evaluate received HTTP headers and payment pages
• Operate at least weekly or as per the entity's risk analysis (Requirement 12.3.1)

Requirement 11.6.1 is a bit more technical. It states that personnel need to be alerted when the HTTP headers and scripts on payment pages change. That they be evaluated when that happens, and a report on them is made at least weekly (requirement 12.3.1 refers to this).

This is less easy to do manually, if not almost impossible. 3rd Party JavaScript is dynamic by design. Some scripts need to serve different versions for functionality reasons. So how can you see let alone understand these changes?

We’d argue it’s only possible with a proxy that serves as a man-in-the-middle. c/side was built this way. It allows you to see every script request, hence the changes in those. In the dashboard, you can see all those versions as well the deobfuscated version of those.

c/side gives you detailed information on the scripts that are loaded on your page, like possible malicious actions, deobfuscated versions, and more.

This makes it easy for engineers to understand what the script is doing. AI also filters out the changes and gives insight to what the added or changed functionality might do.

In the PCI DSS dashboard, we generate a weekly report for your own logs to prove compliance if audited. It shows script on payment pages specifically (as per compliance requirements) as well as on all pages, for full visibility. It also shows you where those 3rd party scripts are running. Should any run on a page where it isn’t supposed to, you assign different rules. This prevents data leaks or inadequate-disclosure, as seen in the Kaiser Permanente HIPAA breach case of 2024.

---

c/side's PCI DSS dashboard.

Get compliant with c/side

Start monitoring and securing 3rd party scripts on your websites today.

Get Started with c/side

We’d argue strongly that 3rd party script monitoring and securing on all pages is of utmost importance. Even though PCI requirements don’t force you, breaches outside of payment pages will get you in a whole lot of other trouble.

The alternatives

Many traditional solutions only aim to check the compliance box, and not deliver the highest level of security.

Crawler-based approaches scan the page after the fact, and often only periodically. These fail to mimic real user behavior and attackers can easily evade detection by serving clean scripts to crawlers while targeting actual users with malicious payloads.

Content Security Policies (CSPs) are limited in scope. They address the script’s source rather than its payload. When the source gets breached, it goes unnoticed. When a dynamic script is used, a Content Security Policy has no way of knowing what that script is actually serving.

Client-Side JS detection (also called Agents) inject monitoring scripts into browsers. They set up traps in order to try and detect malicious JavaScript. Only these traps are usually easily found and as a result avoidable. All these approaches by alternative tools fail to detect dynamic or user-specific threats, leaving critical gaps in protection. Additionally, they often lack the ability to track historical script behavior, reducing their effectiveness against evolving threats.

They fail to detect dynamic or user-specific threats, leaving critical gaps in protection. Client-Side JS Detection ("Agent") These solutions inject monitoring scripts into browsers, but attackers can detect and bypass them. Additionally, they often lack the ability to track historical script behavior, reducing their effectiveness against evolving threats.c/side tackles all of the above mentioned issues by using a proxy solution. This allows us to see every script request and the payload of that code.

We sit in between the 3rd party script and the browser of the user. Ensuring that we have all the data to make the necessary alerts and even block the script before your user is compromised. This data is made available to you in the dashboard, so you can evaluate and make the necessary changes.

If you wish to find another solution as compared to c/side ,legacy code monitoring tools perhaps can perhaps assist with requirements 6.4.3 and 11.6.1. But we implore you to find the security tool that assists beyond these requirements, and delivers the level of security you need.

Our blog features a number of recent attacks, showing the complexity of such 3rd party JavaScript attacks to help you on your journey.

You can get started with c/side right away, or contact us if you are a larger business, enterprise or agency or partner to your own customers.