TL;DR: risk of only protecting payment pages under PCI DSS
- Compliance is not coverage: PCI DSS 4.0 only mandates script monitoring on payment pages, so vendors happily sample 10% of sessions on a handful of URLs and call it compliance, then leave login, KYC, and account pages open to the exact same third-party script class.
- Every page, every session: One compromised CDN-hosted dependency planted four separate backdoors across roughly 1,000 sites simultaneously; cside sits between the third-party and the user on every page, gives full script visibility across 100% of sessions, and often improves performance through cache.
- Before you sign off: Before your next PCI DSS 6.4.3 signoff, decide whether XSS on non-payment pages, session hijack of MFA-authenticated users, and supply-chain attacks on ancillary scripts count as in-scope for your website security program.
Short on time? See cside's in-browser Magecart and skimmer blocking. It covers everything below in one deployment.
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: PCI DSS 4.0 now encourages a shift from annual audits to continuous security monitoring, which means 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.
Supply chain attacks aren't fully blocked either. 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. A single CDN-hosted script from cdn.csyndication[.]com was used to plant four separate backdoors across 1,000 websites simultaneously: one compromised dependency, four attacker footholds.
Remote Code Execution (RCE) and Command Injection vulnerabilities are significant risks that further show why you 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, other pages still carry the risk of being breached.
If that happens, you still run the risk of losing user trust and could face 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. But they're 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.
cside'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 so cside can fetch and analyse them and perform some browser-side detections. This makes cside sit in the flow of the request between the user and the 3rd party script without added latency, and in some cases it even improves performance through caching static scripts.
This gives full insight into the scripts served, across 100% of sessions, and on all pages, protecting both you and your users.
If you want to read more on how our approach differs, go here.
