For years, site owners have been using Subresource Integrity (SRI) as a way to ensure that third-party scripts can’t be tampered with. However, keeping your script up to date is one of its challenges.
Traditional SRI
The idea of Subresource Integrity is great in theory: improved security for site visitors when site owners provide a hash of the script they embed on their site. The browser will refuse to run the file if the provided hash doesn’t match with the contents of the requested file. Security all around.
But it comes with a challenge, both for site owners and third parties.
The challenge with SRI
Most third parties deliver their services through a JavaScript file — whether it’s for tracking (session replay, analytics, monitoring), features (chat widgets, on-site search, reviews, newsletters), or even via a tag manager like GTM. Tools like Hotjar, Cookie Consent, and yes, RUMvision, all fall into this category.
And each has something in common: their JavaScript will change as:
- Bugfixes
Bug fixes or optimizations are shipped by a third party - Updates/upgrades
A new version of a library gets published (our web-vitals dependency is a great example here) - User settings
Site owners change settings of a third party (tracked pages, sampling rate)
Every time the script changes, the hash in your HTML also needs to change. For many site owners, it can take weeks to get such a change approved.
you can’t work to a fixed hash if the file is dynamic: SRI is mooted as you expect the file to change!
Harry Roberts on X
Especially within enterprise business, such a change needs to go through different departments. Ask us how we know!
Our experience at RUMvision
In other words, Subresource Integrity often creates friction for everyone involved: both site owners and third parties like us. And we’ve seen this first-hand.
At one point, we switched our JavaScript agent to a new, more secure AWS beacon endpoint. For most clients, this was no problem: our script updated automatically, and they immediately benefited from the change.
But for customers who had enabled SRI hashes, things got complicated:
- The old endpoint was “engraved” into the JavaScript file, so the file’s contents changed.
- That meant the old hash no longer matched.
- Clients (or their agencies) had to update the SRI hash manually to keep our agent working.
The outcome
The results varied widely:
- Some clients updated the hash quickly, often because the right person was immediately available.
- Others took weeks or longer, since the change had to travel through layers of approvals or wait for the right team member.
- Some gave up and removed SRI entirely, and never re-enabled it.
And this probably is a pattern across the industry. Whenever a SaaS script changes, traditional Subresource Integrity can become a burden rather than a benefit.
Splitting up the dynamic part
We catered to changes to tracking configuration by splitting up the JavaScript file from tracking configuration. In other words, the JavaScript would then fetch a JSON containing the dynamic parts like URL rules and other tracking options.
But this didn’t solve every case, like security fixes or library updates. It also added extra complexity for us to maintain. As we're currently moving to a new stack, this complexity needs to be re-introduced as well.
Say hi to Signature-Based SRI
That’s why we are more than excited about Signature-based SRI.In short, it keeps the security, but removes the operational roadblocks.
Instead of hardcoding a hash of a single file version, browsers can verify a script against a publisher’s digital signature. If the script is signed by the trusted provider (like us), it runs. If it’s not, it’s blocked.
This means:
- Site owners don’t need to constantly update hashes.
- SaaS providers can deliver new versions safely and seamlessly.
- Security isn’t sacrificed for convenience.
Third party support
So far, we haven’t seen other third parties announce support for Signature-based SRI. However, we've been quietly experimenting with Signature-based SRI and are just now writing about it publicly.
Browser support
Signature-based SRI is no longer just a proposal as it is already supported by one browser engine. The current signals from browser vendors are:
- Mozillais evaluating (no formal position published yet) at time of writing.
- WebKitexpressed support for this new security mechanism on February 28, 2025.
- Chromiumalready supports it since version 141, in beta since September 3, 2024.
RUMvision support
And we at RUMvision are already embracing it. We've successfully experimented with Signature-based SRI (SbSRI). Despite the lack of support among all major browsers, we decided to move forward with SbSRI:
- dropped SRI support
In our UI, we removed the option to configure traditional SRI for our tracking agent. - keeping current SRI alive
Existing clients who enabled it earlier can continue to use it without disruption - implementing SbSRI
Our JavaScript agent will always be signed, giving site owners the strongest protection without extra work.
To express our feelings towards this new security mechanism, we proposed Signature-based SRI to Interop 2026 in an attempt to see more browsers adopting this.
Conclusion
For site owners, this means stronger security with less effort. For the web as a whole, it’s a chance to modernize a critical security mechanism. One that’s likely to see broader adoption thanks to its practical advantages.
We’ve taken the leap with Signature-based SRI, and we hope more browser vendors will adopt it to pave the way for other SaaS providers across the web to join in.
