topic Re: Subresource integrity check in APIs & Integrations

Subresource integrity check

Øyvind — Mon, 15 Jun 2020 21:56:02 GMT

I am trying to perform subresource integrity check (https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity) on the hubspot scripts, and I have tried generating a hash for the script on https://js.hs-scripts.com/***.js. This gives me the following error message in the javascript console: Failed to find a valid digest in the 'integrity' attribute for resource 'https://js.hs-scripts.com/***.js' with computed SHA-256 integrity '***'. The resource has been blocked.

Even if this would have worked, I would still have an issue performing a subresource integrity check on all the scripts that are dynamically loaded by the first script.

Is there any way to perform subresource integrity check on the hs scripts?

Re: Subresource integrity check

Derek_Gervais — Thu, 18 Jun 2020 22:02:50 GMT

Hey @Øyvind ,

HubSpot does not have currently plans to introduce automatic SRI hashing for hosted assets. When you host your site on HubSpot, some resources maybe presented by the HubSpot platform from distinct domains (e.g., cdn2.hubspot.net, etc). But those domains and the backend services they represent are under HubSpot's control and are not a 3rd party CDN. The intent of SRI was to solve for situations where a CDN and hosting platform were fully distinct entities with separate protection models; HubSpot's platform is a fully integrated solution with protections applied consistently across its many features.

Re: Subresource integrity check

DHawkings — Tue, 27 Apr 2021 19:00:48 GMT

Hi Derek,

I'm also trying to implement SRI and have the same issue but I'm not using hubspot to host my site. Our hubspot chat is integrated into our site using a javascript pixel. Is there any documentation on adding an integrity attribute to the hubspot script loader and also having the script loader add integrity attributes to all the scripts that it loads?

Here is the pixel that I'm using currently.

Thank you for your help.

Re: Subresource integrity check

Guy_Dawson — Mon, 11 Oct 2021 08:32:49 GMT

Same here! Our main site is on HubSpot but we have another site on which we have HubSpot chat integration.

Each time we do our vulnerability audit the missing SRI on the JavaScript from js.hs-scripts.com and js.hsadspixel.net is highlighed and we have to explain this to our auditors and sometime our cyber-insurance company.

The lack of SRI does make HubSpot look to be a security laggard.

Re: Subresource integrity check

DHawkings — Mon, 14 Mar 2022 18:02:10 GMT

Hi Derek,

I'm just following up on this because we it's still an issue. Even though the HS scripts aren't hosted on a CDN, security audits still flag this as an issue. It would save us time and effort if there was an integrity hash available that could prevent the issue from coming up at all.

Thanks,

David

Re: Subresource integrity check

MSporar — Mon, 04 Dec 2023 19:11:55 GMT

Hi, we're also trying to implement SRI checks into the HubSpot embed and tracking scripts we deploy. Has anyone heard anything new from HubSpot on this? Is this even on their radar? Given all of the current security concerns throughout the web and the threat of scripts being hijacked by malicious actors, I would think that HubSpot would want this done as much as we do.

Re: Subresource integrity check

JamesBBP — Tue, 30 Apr 2024 09:38:19 GMT

Hi, is there any sort of updates on this? 4 years ago there was no plans to implement SRI, is this still the case? We have the same issue where our clients are getting fails on security scorecards due to Hubspot not having an SRI, which is proving to be a serious enough issue that they are considering switching to a different CRM that will provide this.

Re: Subresource integrity check

MSporar — Thu, 02 May 2024 16:18:58 GMT

The intent of SRI was to solve for situations where a CDN and hosting platform were fully distinct entities with separate protection models; HubSpot's platform is a fully integrated solution with protections applied consistently across its many features.

Not accurate at all. The "intent" of SRI is to be an added security layer that enables browsers to verify that resources they fetch (from 3rd party servers) are delivered without unexpected manipulation. In other words, it was to ensure the authenticity of 3rd party resources shared across domains and prevent bad actors from being able to implement malicious scripts through hijacked resources. This directly impacts the browser's CORS policies.

When you host your site on HubSpot, some resources maybe presented by the HubSpot platform from distinct domains (e.g., cdn2.hubspot.net, etc). But those domains and the backend services they represent are under HubSpot's control and are not a 3rd party CDN.

.. again, not quite accurate. Who "owns," "controls," "operates," or "manages" the domains is irrelevant. The fact that they are separate, unique domains apart from the original host domain is what makes them "3rd party domains" as it pertains to how they're treated by web browsers. Scripts coming from these alternate domains must be retrieved across the web, thus opening them up to being interfered with by bad actors.

Additionally, your response fails to consider websites *not* hosted on HubSpot, but use HubSpot embedded scripts to launch HubSpot based "Contact forms", "Calls to Action", "tracking", etc.

SRI is a "necessity," not a "desire." The fact that a large platform like HubSpot has no intent on implementing this feature despite the fact it was introduced 8 years ago (2016) and all the *new* security enhancements, protections, and features across all web browsers are becoming more and more restrictive is quite disturbing. Not to mention, as JamesBBP pointed out, this is a direct cause of security check failures on many analysis platforms (ie: MOZ), and having the transcending effect of causing clients to look elsewhere for their web-development services.

This is counter-productive to the development community at large which is under constant pressure and scrutiny to comply with modern web security policies.

HubSpot really needs to re-evaluate their position and consider its clientele.

Re: Subresource integrity check

PamCotton — Tue, 30 Apr 2024 22:40:32 GMT

Hey @JamesBBP, what is currently happening on your end? The more information, screenshots, and details you can provide, the better I can advise on the next steps.

Kindly,

Pam

Re: Subresource integrity check

JamesBBP — Thu, 02 May 2024 09:12:45 GMT

Hi,

There is no way to implement hubspot embedded forms using a Subresource integrity check for the scripts, this is causing our clients security checks to fail, as MSporar says below it doesn't really matter that the files are hosted by hubspot, there is any number of things a malicious actor could do to send a different file from the domain to a user, the SRI is intended to ensure that exactly the expected file is delivered, or offer a self hosted version of the scripts that users can download and host on their own domains

Re: Subresource integrity check

davidrevis — Thu, 01 Aug 2024 08:21:28 GMT

Agree totally, we are also getting marked down on security scorecard and the fact that Hubspoty cant help is not a great response.

Re: Subresource integrity check

JessieS — Tue, 22 Oct 2024 00:46:12 GMT

+1 for a customer hoping to add this "as a verification mechanism to prevent malicious JavaScript from loading from a third party website, if the site is compromised." They are noted a SRI integrity hash would need to be generated for each resource to validate the script/stylesheet.

Re: Subresource integrity check

MSporar — Wed, 23 Oct 2024 18:03:53 GMT

It won't work for a HubSpot customer to add it. It needs to be added by the developers who update the scripts on the host server. And in HubSpot's case, that could be any where from 5-40 associated scripts that are sourced for each HubSpot JS injectin placed into a website. HubSpot is failing its customers by not doing this on their end. It's creating a real issue for developers that are responsible for tighter / stricter website secutiry and keeping their sites locked down and protected.

Re: Subresource integrity check

BMoles1 — Wed, 29 Oct 2025 16:18:55 GMT

Reason 1 to implement this security measure:
When a resource is referenced on the HTML code with a different domain from which the same HTML was loaded, then a malicious actor could interfere in the DNS resolution on the end user's machine, to make the resource be downloaded from a different location. Thus, a resource referenced with "https://js.hs-scripts.com/***.js" could be downloaded from a malicious server with malicious code. This type of attack can be prevented if HubSpot adds a verification string that allows the browser to confirm that the received asset is the expected one, without alterations.

Reason 2 to implement this security measure:
Even if there is no attack from a malicious actor. Security audits rise this security flaw as a vulnerability, causing reputational damage to the people maintaning the website and to the website's owner.

Please provide a solution to this.

Re: Subresource integrity check

Jaycee_Lewis — Wed, 29 Oct 2025 17:06:35 GMT

Hey, @BMoles1 👋 Welcome to our community. Thank you for your suggestion. Please note, this is a peer-to-peer support community.

If you have a moment, there are two places to add your feedback so the product team sees it:

HubSpot Developer Feedback form
HubSpot Ideas Forum (I searched but didn't find an existing match)

Best,

Jaycee

Re: Subresource integrity check

s-mon — Thu, 27 Nov 2025 01:00:41 GMT

Hey,

You're bumping into the client-side security rabbit hole here. Tools like HubSpot and pretty much any client-side tool (analytics, ads, fraud detection...) are dynamic by design.

HubSpot's scripts are dynamic. They change based on your account config, feature flags, user location, A/B testing, etc. SRI uses a cryptographic fingerprint that breaks the moment content changes. So you'd either be constantly updating these fingerprints or your forms would just break and impact your business.

Even if HubSpot provided integrity values for some static base script, most of the actual functionality comes from additional scripts it loads dynamically and those bypass SRI entirely.

What you're really trying to protect against is the script doing something malicious, right?

Integrity validation just tells you if the script contents hasn't changed and if it did it wouldn't load. Most people don't want that burden on their shoulders. And to make matters worse if there is a subrequest URL in that payload and that subrequest changed... out of luck.

On top of that, we see HubSpot buying and using new domains a lot and there is no consistency. Using different notation patterns, hs-analytics but then hsforms on another domain (just a hypothetical I'd have to dig for the exact examples)...

More practical approach: monitor what scripts actually do in the browser.

What data do they access?

Where do they send it?

When does behavior change?

This works regardless of whether content is static or dynamic.

CSP with script-src can also help, but if hubspot.com is allowed and serves something malicious CSP will not stop it.

This is a particularly bad problem with googleanalytics.com since bad actors just use that to distribute bad code and no real validation there happens.

Now, don't be tempted to just trust using a scanner here because to your findings, scripts change. Bad actors will not perform the bad actions nor serve the malicious payload if they notice a request from a scanner or some vendors call these things 'agent-less' solutions. Sure, for privacy those approaches may cover enough but not for a security incident where a once trusted vendor is now compromised.

Not trying to freak you out, HubSpot is probably fine. But if you're in a regulated space (PCI, HIPAA, etc.), compliance is starting to require runtime monitoring of client-side scripts because this is where most data breaches actually happen now. Bad actors know you do a lot to protect data at rest, server side stuff and open source dependencies but what actually happens in the browser? *shrug*

Full disclosure: I work at cside, building tools for this. But the technical limitations of SRI and CSP for dynamic scripts are real regardless of which solution you use.

Re: Subresource integrity check

BMoles1 — Tue, 03 Mar 2026 16:12:16 GMT

Taking s-mon's comment (on ‎Nov 26, 2025 8:00 PM) as "Solution" is disappointing. The comment discusses the challenges of implementing the requested feature and talks about other risks with their respective solution approaches (monitor what scripts actually do in the browser).

The suggested apprach is way more complex, and has is drawbacks, making it suitable for some scenarios and not for other. That is why "Subresource integrity check" exists and makes sense.

There may be scenarios where "Subresource integrity check" doesn't fit well. Making it optional would solve the issue.

The lack of ability to use "Subresource integrity check" is not solved and the scenarios where it is useful are still unsupported. Hubspot doesn't allow its websites to benefit from this standard security feature. Closing this feature request without its implementation is disappointing.

Re: Subresource integrity check

Guy_Dawson — Tue, 03 Mar 2026 18:04:59 GMT

This is not a solution for us.

Here in the UK things like Cyber Essentials Plus and ISO 27001 necessitate
a proper solution.

Re: Subresource integrity check

Victor_Becerra — Tue, 03 Mar 2026 18:49:56 GMT

Hi @Guy_Dawson, and thanks for adding to the thread!

I found a HubSpot Ideas post specifically related to your issue:

https://community.hubspot.com/t5/HubSpot-Ideas/Support-Subresource-Integrity-SRI/idi-p/1218003

I would recommend:

Upvote the idea

Add a comment describing your specific use case

Please let me know if you have any more questions. Thanks!

Victor