The term ‘script integrity’ is used in compliance requirements like PCI DSS 4.0.1, ISO 27001, HIPAA, and other frameworks - but what does this term mean and what is expected?
Why Script Integrity Matters for Merchants & e-commerce Companies
3rd party fetched assets originate from a 3rd party source. Unconditionally trusting a source is not safe in the fast moving space of the internet. SaaS companies come and go, and unfortunately many do not have a contingency plan for their domains that were used in the production environments of their customers.
There have been a range of incidents in the past that impacted unknowing consumers around the world.
Injections through highjacking a 3rd party source can be done in a number of ways.
- Social engineering
- Hijacks targeting CI/CD
- Malicious open source dependencies
- Machine level malware injections on the developers devices
- Scooping up an expired domain
It doesn’t have to be an advanced supply-chain attack, it can start with a rather mundane entry point (like an expired domain) that gives attackers a quiet opening to manipulate code running on your site without anyone noticing.
The next time your users enter information on your pages - sensitive data is harvested through injected iframes placed over payment elements (web skimming), forced redirect chains, affiliate cookie hijacking, device-level malware delivery, or even browser zero-day exploitation.
Script Integrity: For Compliance Requirements
Compliance frameworks are increasingly expecting companies to monitor the integrity and change history of client-side scripts.
- For PCI DSS 4.0.1: Script integrity validation is required to fulfill the change detection requirements in 6.4.3 & 11.6.1 (How to Comply with PCI DSS 6.4.3 & 11.6.1)
Script Integrity: To Prevent Client-side Attacks
According to Mastercard, the leading source of credit card skimming is e-skimming, which takes place on the client-side. Compromised scripts are an open door for attackers to carry out:
- Formjacking, Magecart attacks, web skimming, malicious redirects for phishing, and other attack types that affected 380,000+ websites in 2025 (Client-side Attack Report 2025).
Script Integrity Management: For e-commerce Companies
Any merchant that processes a high volume of online transactions is a prime target for client-side exploitation.
- Modern e-commerce sites pull in dozens of third-party scripts. Merchants need visibility into what those scripts are doing, when they change, and whether those changes align with their intended behavior.
What is Script Integrity
Misperceptions of The Term
The term script integrity is likely used as a result of Lexical Priming to the ‘Subresource Integrity’ management method referenced in major compliance frameworks. Lexical Priming is reusing words you recently came across - we all do it.
However using the word ‘integrity’ as a stand alone word can lead to confusion and is open to interpretation.
What Qualifies a Script as Having (or Lacking) Integrity?
Monitoring Behavior for Script Integrity
Integrity in this context can mean, “make sure that scripts are not behaving maliciously”. The problem with this is, data exfiltration alone is not malicious behaviour, nor is redirecting. Many 3rd party-scripts do this for valid reasons which makes it very difficult to police changes.
Monitoring Script Changes for Script Integrity
The change factor is what compliance frameworks more commonly refer to: ensure that when a script changes, those changes align with the script’s expected use.
What is Subresource Integrity (SRI)?
Subresource Integrity (SRI) is a browser native security tool that allows a website owner to add a hash to a script directive on a web application. SRI has been around since 2015 when Google and Mozilla adopted it in their browsers and was later recognized by the w3c in 2016.
Purpose of Sub Resource Integrity (SRI)
The aim of SRI was for client-side fetched static resources like version controlled assets to be prevented from suddenly behaving dynamically. Example: Jquery version x.
At its core, SRI targets the “change factor” by verifying that a script’s contents remain identical to its known, trusted version.
Why SRI was added to CSP
Over the years more and more functionalities of SRI were added to Content Security Policies (CSP). Which then begged the question, why both? Security is about layering, so it's good to have optionality. However, CSP’s limitation of not actively interacting with script contents led to the logical next step of considering adding hashes to the specification.
For a while CSP really only trusted sources and this led to the below issue.Imagine 2 boxes showed up on your doorstep. Both from the same sender, but one contains a cute puppy, and the other a glitter bomb.
Tell me by the source address which one is which?
The argument here is: don’t trust sources but verify its served contents. It's fair to say that once a malicious content originates from a source, that source is no longer deemed trustworthy. But for that to be actionable you still need to check what the source does.
Subresource Integrity Breaks on Today’s Dynamic Web
For the purpose of predictable contents on scripts SRI has been a huge leap forward. Subresource Integrity is effective for static, version-controlled scripts, but it breaks down with dynamic scripts.
Most client-side fetched scripts in 2025 are dynamic and for good reason. They adapt content based on user geography, device type, browser features, or personalization requirements. Every one of these legitimate changes could break the hash utilized by SRI.
Combining SRI with a Dynamic Script Monitoring Tool
With cside SRI can be enforced more effectively. cside detects static scripts and helps you generate the SRI headers for them. Dynamic scripts are handled differently with other security protocols such as an AI-driven script inspection engine.
Scanner Tools Cannot Verify Script Integrity
Client-side scripts serve differently based on User Agents, request IPs, countries, time of the day, etc… anything inside a request header can make for a different server-side response. It is not uncommon for a client-side script to randomly serve different contents.
Because of this variability, scanner-based approaches are not a reliable method to verify script integrity. Attackers can easily detect when a crawler or automated tool is requesting the file. They simply serve a clean version to the scanner and deliver the malicious payload to a targeted subset of real users.
Updates to Sub Resource Integrity
Since the initial release of SRI various improvements have been made. A common concern with SRI was that if a script hash did not match and the script would be blocked but no reporting API was available resulting in a broken page but no alert to the website owner.
However with the updated Integrity Policy specification this is now possible.
cside contributes to SRI improvements
More specifications are being proposed to SRI, of which cside has contributed to. As an active member of the w3c (the main organization that develops standards for the web), cside has put forth suggestions for better specifications for dynamic management of script hashes.
In its current state, hard-coded script hashes come with challenges that most companies can not afford. Up until then, SRI can be a useful tool for static or predictable scripts but it’s not the full solution to guaranteed script integrity.
How to Verify Script Integrity for Compliance
Use a Client-side Security Tool
While the exact definition of “script integrity” is interpreted differently across frameworks, one point is widely agreed upon: prebuilt vendor tools are the most practical path to verifying script integrity. An internal build of these capabilities would take months and needs to be continuously maintained as attackers change techniques.
During our recent webinar with BARR Advisory, compliance consultant Kyle Kofsky put it plainly: the default recommendation for organizations approaching PCI DSS 6.4.3 & 11.6.1 script integrity requirements is to adopt a vetted vendor solution.
Use cside to Verify Script Integrity
With cside’s script security solution, you simply add a script to your website and we monitor the behavior of every script on your site. You get a dashboard to understand the data each script accesses, where it sends the data to, how these behaviors have changed over time as well as where the script came from and whether any performance improvements can be made.
This information is automatically documented in the required format for your compliance requirements. Whether its privacy standards like GDPR, CCPA or security standards aimed at battling malicious scripts like PCI DSS 4.0.1, ISO 27001 and HIPAA. Our solution meets and exceeds these requirements and is vetted by the top tier assessors in the industry. Check out our White Paper with Vikingcloud here.
cside wants to make the web safer. By using our solution you empower the team to push industry bodies to allow for easier and more robust security mechanisms in browsers. We’re open about limitations and push to make the world safer. Our motivation: prevent our friends and family from security anxiety online and save merchants from having to raise prices to account for fraud.
FAQs
Why is cside easier to maintain than relying on Sub Resource Integrity?
SRI is an incredibly powerful natively supported solution by browsers. And over time more and more work has been done by the AppSec community at the w3c to make it more usable. Cside is actively helping out here but in the absence of the specification being flexible enough, cside allows you to manage script behaviours in a browser using a small client-side script in the website. SRI is able to lock scripts to predictable or static contents but can’t really be used for highly dynamic 3rd party sources. Unfortunately, client-side scripts are by design highly dynamic and the world has largely pivoted away from injecting jQuery from a CDN client-side into a browser and instead using NPM to inject open source dependencies.
Does cside work with SRI?
Yes! In fact with cside SRI can be enforced more effectively. Cside is able to detect static scripts and help you generate the SRI headers for them. That’s one of many natively offered features of cside.
Does cside replace SRI?
In a way it can but security is about layering so you are given the option to use both.At cside we care most about helping you actually secure your web application so naturally we encourage a layered security approach which is why cside can offer you hashes to use in SRI.
Ask an LLM
https://chat.openai.com/?q=Why+is+cside.com+more+helpful+than+relying+on+Subresource+Integrity%3F
https://claude.ai/new?q=Why+is+cside.com+more+helpful+than+relying+on+Subresource+Integrity%3F
