Teams depend on external JavaScript to power everyday features, such as:
- Marketing & analytics trackers
- Ad network pixels
- CDN-hosted JS libraries and fonts
- Chatbots and support widgets
- A/B testing and personalization tools
- Tag managers (which may load even more scripts)
These tools help teams move fast. But they also introduce code paths that security teams rarely review.
Third-Party Scripts Change Without Notice
Most third-party JavaScript is dynamic by design:
- Vendors update scripts at the CDN level.
- Code renders differently based on geography, device, or A/B experiment.
- Tag managers can inject new scripts with a single toggle.
- Marketing teams run tests without engineering oversight.
So third-party scripts are constantly changing. Your team may never see these changes because they happen outside your codebase. In many companies, no one is monitoring these shifts at all
That Makes Third-Party Script a Prime Attack Target
Attackers go where defenses are weakest. And today, that’s the JavaScript supply chain that executes in user browsers.
Client-side attacks (like e-skimming, formjacking, and malicious script injection) often succeed because companies do not have a security tool that monitors how third party scripts execute in their user’s browsers.
What is Script Integrity?
Script integrity is the practice of ensuring that a third party script on your site is behav the way it was intended. In other words, it answers a simple but critical question: Is the code executing in a user’s browser the same code you approved?
Verifying That Scripts Haven’t Been Tampered With
This means confirming that the JavaScript loaded by your website hasn’t been altered by attackers, compromised vendors, unexpected CDN updates, or unauthorized changes introduced through tag managers or other integrations.
Ensuring Scripts Behave the Way They Should
Integrity isn’t only about matching what’s on disk. It’s also about verifying behavior. A script may load from an allowed source but still perform new or unexpected actions, such as:
- Sending data to unfamiliar domains
- Capturing keystrokes on form fields
- Loading new, hidden “shadow scripts”
- Making API calls that were never part of its original purpose
A script can be “valid” yet still be dangerous. That’s why real integrity validation is both structural and behavioral.
The Main Ways Teams Try to Verify Script Integrity
There are a few popular methods teams use to verify script integrity to meet PCI DSS requirements.
1: CSP + SRI (Static Integrity Controls)
Content Security Policy (CSP) and Subresource Integrity (SRI) are often the first tools developers reach for because they’re natively supported by modern browsers. CSP restricts which domains scripts are allowed to load from, while SRI uses cryptographic hashes to ensure a script hasn’t been modified.
Where CSP + SRI help:
- They create basic guardrails that prevent obvious misuse, like unauthorized domains or altered static files.
- They’re easy to adopt for static assets that rarely change.
- They provide a minimum standard of governance for external scripts.
Where CSP + SRI struggle:
- Most third-party scripts update constantly, which breaks SRI hashes unless someone manually updates them.
- CSP cannot detect malicious logic inside an allowed domain.
- Many scripts load nested dependencies that CSP rules don’t fully protect.
- Tag managers, consent tools, and dynamic CDNs change script behavior at runtime, bypassing what CSP and SRI were originally designed for.
- They offer no insights into what a script is doing once it loads.
2. Scanner Tools or Crawlers
Scanner tools analyze your website from the outside by crawling pages, inspecting network requests, mapping third-party technologies, and flagging risky behaviors or outdated components.
Where scanner tools fall short:
- They take point-in time snapshots meaning they miss the vast majority of changes that happen between scans.
- They can be evaded with conditional delivery, such as malicious code that only activates for certain geographies, browsers, payment pages, or returning users.
3. Real-Time Monitoring & Script Behavior Analysis
Real-time monitoring tools take a fundamentally different approach from CSP, SRI, or periodic scanners because they observe scripts as they execute inside the browser.
Where real-time monitoring excels:
- It provides visibility into behavioral anomalies, such as scripts sending data to new destinations collecting unusual user inputs, injecting iframes, or loading shadow scripts that scanners and CSP policies often miss.
- It works with the modern web’s dynamic architecture, where code can change several times per day and where user experience platforms routinely rewrite or augment JavaScript in real time.
- It generates audit-ready evidence that aligns with PCI DSS 6.4.3 and 11.6.1, which require organizations to detect unauthorized script activity and demonstrate continuous integrity verification.
Tools like cside automate script integrity monitoring for PCI DSS compliance and help teams avoid data leaks or data skimming that violate website privacy compliance laws.
Why CSP + SRI Would Miss an Expired Domain Attack
Expired domain attacks exploit a blind spot in traditional client-side controls: both CSP and SRI assume that a previously trusted domain will remain safe over time. When that domain expires and is purchased by an attacker (exactly what happened in the Oracle example where ociforums.com became available for sale) the domain is still treated as legitimate because the URL looks exactly the same. The ownership changed. A potential risk factor was introduced. But the URL stays the same.
Why CSP Fails
CSP validates the origin of the resource, not whether the owner of that origin is still trustworthy. If the expired domain was on your CSP allowlist at any point, CSP will continue allowing requests to it even after an attacker takes control
Why SRI Fails
SRI protects against sudden changes in file contents. In the Oracle example, the expired domain wasn’t even a script reference, it was a hyperlink directly embedded in Oracle’s JavaScript code. Even without changing the code, the attacker could redirect that hyperlink to a phishing site that looked identical to the original OCI forum site. On that look alike site, users might be asked to enter login credentials. Suddenly, their credentials have been skimmed from a “trusted” website linked from an official Oracle page.
Mapping Script Integrity Approaches to PCI DSS 6.4.3 & 11.6.1
How different approaches map to 6.4.3:
- CSP + SRI: Help validate origin and static file integrity, but do not detect runtime changes, nested dependencies, or behavior modifications.
- Scanner tools: Offer partial visibility by showing which scripts load during a scan, but they miss changes that occur between scans.
- Real-time monitoring: Tracks script additions, removals, and modifications as they occur, fulfilling the requirement for ongoing verification.
Practical Takeaways for Compliance
To satisfy both requirements, organizations typically adopt a layered approach:
- CSP → Baseline origin control
- SRI → Integrity checks for static, first-party files
- Scanner tools → Periodic visibility and inventory
- Real-time monitoring → Required for PCI-grade detection and integrity auditing
