Unsafe Implementation Of Subresource Integrity | Community
Skip to main content
Answered

Unsafe Implementation Of Subresource Integrity

  • June 24, 2026
  • 1 reply
  • 219 views
A

Our subdomain managed by intercom was flagged as ‘Unsafe Implementation Of Subresource Integrity’ issue.

"Unsafe Implementation of Subresource Integrity" usually comes from a scanner flagging that you're loading external scripts or stylesheets (typically from a CDN or third-party service) either without an integrity attribute, with a weak hash, or with integrity present but missing crossorigin. Subresource Integrity (SRI) lets the browser verify that a fetched file hasn't been tampered with by comparing it against a cryptographic hash you specify.

Can you do something to mitigate this? Like


<script
  src="https://cdn.example.com/library@1.2.3/file.min.js"
  integrity="sha384-<hash>"
  crossorigin="anonymous"></script>
 

Best answer by Dara K

Hey ​@Andrey Vorobyov , 

Thanks for flagging this.

If the finding is for an Intercom-managed Help Center subdomain, this is not something we can mitigate by manually adding integrity / crossorigin attributes to the Help Center asset tags today.

The reason is that those Help Center assets are served from static.intercomassets.eu, which is a separate domain, but it is still fully owned and operated by Intercom and used for performance reasons such as caching and cookie-free delivery. In other words, this is not the typical third-party CDN risk that Subresource Integrity is designed to protect against.

Because of that, security scanners can sometimes flag this as a cross-origin SRI issue even though both the Help Center application and the asset delivery domain are part of Intercom’s infrastructure. Our understanding is that this is generally a scanner false positive in this context.

So, to answer your question directly:

  • there is not currently a supported change we can make on Intercom-hosted Help Center pages to add SRI in the way shown in your example,

  • and the recommended interpretation is that this finding is due to automated scanning logic rather than an exposed third-party asset chain.

    1 reply

    D
    Intercom Team
    Forum|alt.badge.img+5
    • Dara KIntercom Team
    • Intercom Team
    • Answer
    • July 16, 2026

    Hey ​@Andrey Vorobyov , 

    Thanks for flagging this.

    If the finding is for an Intercom-managed Help Center subdomain, this is not something we can mitigate by manually adding integrity / crossorigin attributes to the Help Center asset tags today.

    The reason is that those Help Center assets are served from static.intercomassets.eu, which is a separate domain, but it is still fully owned and operated by Intercom and used for performance reasons such as caching and cookie-free delivery. In other words, this is not the typical third-party CDN risk that Subresource Integrity is designed to protect against.

    Because of that, security scanners can sometimes flag this as a cross-origin SRI issue even though both the Help Center application and the asset delivery domain are part of Intercom’s infrastructure. Our understanding is that this is generally a scanner false positive in this context.

    So, to answer your question directly:

    • there is not currently a supported change we can make on Intercom-hosted Help Center pages to add SRI in the way shown in your example,

    • and the recommended interpretation is that this finding is due to automated scanning logic rather than an exposed third-party asset chain.

    Terms & ConditionsAccessibility statement