PCI 6.4.3 - What Solutions Will Keep Your Website Compliant?

If you’re on top of your compliance roadmap, you’ll know that PCI-DSS just got a facelift, affectionately termed v4. The guidelines present a number of solutions to protect public-facing web applications from threats such as Magecart or web skimming attacks, but which will keep you the most secure at the end of the day?

What are my new requirements under section 6.4 of PCI-DSS v4?

This section of PCI-DSS v4 is titled, public facing web applications are protected against attacks. According to the updated regulations, “poorly coded web applications provide an easy path for attackers to gain access to sensitive data and systems.” Without visibility into each and every script, many of which are handled by third parties, not by your own organization, it’s impossible to ensure that there aren’t vulnerabilities.

The guidelines dictate that businesses must address the threats and vulnerabilities on an ongoing basis, by reviewing all public-facing web applications either manually or using automation at least once each year, and any time there are significant changes, and this task must be done by an expert in application security. Vulnerabilities must be ranked, corrected, and then applications re-evaluated. If chosen, an automated solution should continually detect and prevent web-based attacks by being installed in front of public-facing web apps to detect and prevent threats, and generate audit logs and alerts that can be investigated where necessary.

In particular, 6.4.3 discusses payment page scripts, and comments that ”all payment page scripts that are loaded and executed in the consumer’s browser are managed as follows”:

A method is implemented to confirm that each script is authorized.
A method is implemented to assure the integrity of each script.
An inventory of all scripts is maintained with written justification as to why each is necessary

As scripts that are loaded and executed on payments pages could be tampered with or altered without your business being aware, malicious scripts could be uploaded that steal credentials or other sensitive information such as cardholder data. Of course, these scripts are essential to take payments and ensure the payment page operates properly, so visibility and control is essential to strike the right balance. If scripts are explicitly authorized, this minimizes the likelihood of an attack through this vector.

What options do I have for following this requirement?

The regulatory recommendations put forward specific solutions that businesses can use to fulfill this requirement when the best-practices become a regulatory standard in 2025. Two of these are Sub Resource integrity (SRI) and Content Security Policy (CSP). Let’s look at each in more detail.

SRI, or Sub Resource Integrity

This technique allows the consumer’s browser to validate that a script has not been tampered with. In practice, it means you sign and hash every single script that is hosted on your website. If the script has been changed or altered in any way, it will be not executed by the consumer browser, and not be able to run on the consumer browser, the client-side.

In theory, this is a great solution. If a script doesn’t look correct – it’s immediately blocked. However, for it to work, you need to know all of the scripts that are running on your website, (and today, most businesses have 1000+), manage a list of all third-party and fourth-party scripts so that you can mark them as secure, and also be able to sign them in a timely fashion every time a new version is released. This would be one thing if it’s only your own scripts, but what about your third parties? They might release a new version daily, especially with CI/CD pipelines, and you need to be able to verify and sign each of these releases, or your payment page may be unusable. Forget just once, and you could destroy customer experience altogether.

In practice, you are unlikely to be able to sign even 5% of your whole inventory, and SRI is really best used for your own internal scripts that you can be fully sure about and have enough resources to maintain.

CSP, or Content Security Policy

Your Content Security Policy can limit the locations that the consumer browser can pull a script from, or send data to. The way it works is low-cost and straightforward, relying on your dev teams adding a CSP HTTP response header into the webpage, and then creating rules about scripts, media, forms and more. Actions that fall outside of these policies are blocked.

While a CSP is an important part of your security arsenal, it has some limitations. You’ll need to use a blacklist and whitelist approach, which means choosing which domains are trusted and which are not. You’re not controlling actions, you’re controlling which domains you trust. That means if an attacker manages to get hold of a “trusted” domain, they will be allowed access to make changes. Many famous web skimming attacks injected malicious code from trusted and even owned servers, which a CSP is almost certainly going to have approved.

Relying on CSP is a heavily manual task which will leave you putting full-time resources into managing policies and updating the whitelists and blacklists, and approving non-risky changes to scripts. Even then, you’re likely to have gaps or vulnerabilities due to trusted third-parties who could well be manipulated themselves.

Enhancing your Ability to Remain Compliant

Reflectiz is an example of a proprietary solution that is purpose-built to handle this challenge, without adding heavy resource investment to the mix. The solution is an all-in-one platform for client-side risks, including those laid out in section 6.4 of the new PCI-DSS regulations. Behind the scenes, and without any code injection on your website, the platform maintains a complete and comprehensive list of all third and fourth party scripts, explaining why they are necessary – exactly what PCI DSS requests. It scans all scripts and applications, and provides the peace of mind that they are all running with integrity.

When changes occur, even if they come from a trusted domain or an application that you would whitelist on a CSP, your security teams have immediate visibility into what’s happening in your digital environment. You can choose what alerts you receive and for what events, and you’ll see all outcomes ranked from low-risk to critical to make mitigation fast and easy.

PCI-DSS only requests this visibility and control is gained on payment pages, but Reflectiz provides the same insight across your entire website, so that login details, sensitive chat information or any other personal data such as post-authentication scans are fully protected.