PCI DSS 4.0 is here. By March 2025, it mandates that payment portals need to have a way to authorize each script on payment pages. Websites need to maintain an inventory of all scripts (on those payment portals at least) and ensure their integrity. You now need to detect and respond to unauthorized modifications on payment pages, including changes to HTTP headers and page contents. Organizations must check these configurations at least once every seven days or as determined by their risk analysis assessment.
Read the full requirements here.
Another important line in there is that PCI DSS 4.0 now encourages a shift from annual audits to continuous security monitoring, involving regular reviews and updates of system components and software.
Finally!
At this time, only payment portals are required to have a system to keep 3rd party JavaScript in check. This is why a lot of our competitors (read what we think about them here) limit their services to only a few pages. Some even sample the session, so only 10% of sessions are protected.
But that's asking for problems.
Why you should protect all pages
There’s still a data breach risk if you don’t secure all pages.
Bad actors could use compromised scripts on other parts of your site to hijack user sessions. This could allow them to impersonate legitimate users and perform unauthorized actions, potentially even bypassing some forms of two-factor authentication. That would potentially circumvent your third-party script protection on payment portals.
Another area that you’d leave open to risk, is Cross-site scripting (XSS) vulnerabilities. They allow attackers to inject malicious scripts into web pages viewed by other users. If only the payment portal is protected, other pages could be exploited to execute XSS attacks, affecting users’ data and privacy anyway.
Even in some cases, Supply Chain Attacks are not totally blocked. Third-party scripts are a common vector for supply chain attacks. If attackers compromise a vendor or a script that is used across your site, focusing protections only on the payment portal won't prevent exploitation through other third-party integrations.
Remote Code Execution (RCE) and Command Injection vulnerabilities represent significant security risks that further emphasize the need to secure all pages, not just critical areas like payment portals. RCE allows attackers to execute arbitrary code on your server, potentially leading to complete system compromise. This can occur through unsafe handling of user inputs, such as evaluating code uploaded by users or injected through form fields.
Command Injection vulnerabilities arise when unsafe user inputs are executed as system commands, particularly through improperly sanitized JavaScript inputs. This can enable attackers to manipulate server actions or access backend databases, leading to unauthorized data changes or theft.
Finally, social engineering and phishing are a real threat. Attackers could modify content or redirect users to malicious sites, tricking them into providing sensitive information.
Other vulnerabilities
Even if your payment portals are protected, and the protection works, you still pose a risk of scripts on other pages being breached as we’ve established.
If that happens, you still run the risk of losing user trust and potentially have legal or regulatory implications, especially concerning data protection laws like GDPR or CCPA. The damages in fees coming from that, or reputational damage are hard to quantify. Nevertheless, it’s there.
So do it right, right away
Just like the PCI DSS 4.0 rules, we also encourage any site owner to adopt continuous security monitoring. And I hope we’ve made the case that doing it on all pages is the best way.
c/side’s free tier makes your site PCI DSS compliant regarding third-party scripts, and it runs on all pages. Our approach is different from the competition, however. Our script rewrites sources of other scripts on your site to proxy them through c/side and perform some browser-side detections. Making c/side sit in the flow of the request between the user and the 3rd party script without added latency, and in some cases even improving performance through caching static scripts.
This allows full insight into the scripts served, 100% of the session, and on all pages. Protecting both you and your users.
If you want to read more on how our approach differs, go here.