Hey again @stefan m​ . 👋

I replied to your other post with an answer here but just incase that didn't show I'll copy my message here.

"Currently 'unsafe-inline' is required for various aspects of Intercom to work properly. If you choose not to include one or some of the policies listed in that article you have looked at, then Intercom will potentially not function correctly.

You definitely aren't the first to reach out about our CSP so I will make sure to flag this with our Product team so they aware of it. I hope this clarifies."

@evan p​ 

Thanks for your reply 👍

@Evan P Hello Evan,

Any progress on using Intercom with CSP?

Pascal

Hi @Pascal Bourque , It’s Mat from the Support Engineering Team

We are constantly working to enhance the intercom. 

You can find more about using CSP in Intercom in this article.

Please let me know if that was the answer you were looking for

Hey Mat

Thanks for the update! There still seems to be a requirement to include

style-src:
  'unsafe-inline’

Is there any way to avoid this, or any updates underway? 

This is quite crucial for us & cybersecurity in general.

Hey there @Dries Hendrickx !

That ‘unsafe-inline’ has been flagged with our team, but as of right now it is still a requirement.

Is there any progress on this? We will not be able to use Intercom in certain client environments due to strict CSP rules (as defined by Dutch Government). Hopefully this will be soon be compliant?

Content Security Policy (CSP), I think it's helpful for any website.

+1

This has been flagged to the team for over 2 years. Any updates? Requiring the whole website to allow `unsafe-inline`, lowering security, just to be able use Intercom is not a good look. This is getting flagged during pentesting.

​@kevindqc 

 

Intercom supports Google's strict Content Security Policy (CSP) version 3, which allows you to specify a policy that does not require 'unsafe-inline' for script sources. This means you can configure your CSP without lowering your website's security to use Intercom. The recommended directives for script sources include a nonce-source or source allowlisting if you cannot use CSPv2 or v3 features. For style sources, 'unsafe-inline' can be used, but if you include nonces in your style-src directive, 'unsafe-inline' will be ignored, and only styles with a matching nonce will be applied. To ensure compatibility with Intercom and maintain your website's security, you should refer to the specific CSP settings provided by Intercom, which detail the domains and configurations that should be whitelisted. Additionally, here is a list of domains you may need to whitelist for Intercom's script and style sources:

• For script-src:
  • https://video-messages.intercomcdn.com
  • https://messenger-apps.intercom.io
  • https://messenger-apps.eu.intercom.io
  • https://messenger-apps.au.intercom.io
  • And other Intercom-related domains.
• For style-src:
  • 'unsafe-inline'

Please note that while 'unsafe-inline' is listed for style-src, the presence of nonces will override this setting, and you will need to ensure that the nonces match those used by Intercom's inline styles.

​@mateusz.leszkiewicz 

How should I read this part:
 

If I’ll manually add nonce to auto-generated by Intercom <style>’s then it will work? Kind of obvious but it will be already raised as an error by the browser because initially those <style>’s were without nonce.

Or there’s some other/better workaround?

Will be perfect if Intercom can simply take nonce from site’s meta-tag and apply to its styles - this is how others are doing this.

Thanks!

I’ve found these possible Workarounds but you will have to test which one will work with your setup.
 

1. Use a CSP Compatible with Intercom

Intercom suggests using 'unsafe-inline' for style-src as a default, but this lowers security. To enhance security, you could:

• Allow 'unsafe-inline' only for specific trusted styles (like Intercom).
• Example:

  style-src 'self' 'unsafe-inline' https://*.intercomcdn.com;

  This setup permits Intercom’s inline styles without globally lowering your site's CSP.

2. Whitelist Intercom Domains

Ensure that all required Intercom domains for script-src and style-src are whitelisted:

• Example CSP:

  script-src 'self' 'nonce-<your-nonce>' https://*.intercomcdn.com https://*.intercom.io; style-src 'self' 'nonce-<your-nonce>' 'unsafe-inline' https://*.intercomcdn.com;

3. Use hash for Inline Styles

If you want to avoid 'unsafe-inline', and if the injected styles are predictable:

1. Calculate the hash of the inline styles that Intercom generates.

2. Add the hash to your CSP style-src directive.

   • Example:

     style-src 'self' 'sha256-<calculated-hash>' https://*.intercomcdn.com;

   However, this can be challenging if styles change dynamically or vary between pages.

4. Engage Intercom Support for Nonce Integration

Currently, Intercom doesn’t natively support reading or applying your CSP nonce to its injected styles. You could:

• File a feature request or ask Intercom support about adding nonce support, as other providers do.
• Suggested functionality:
  • Intercom reads your CSP nonce meta tag and applies it to its injected styles.

For now, a pragmatic CSP for Intercom that balances security and functionality might look like this:

Content-Security-Policy: script-src 'self' 'nonce-<your-nonce>' https://*.intercomcdn.com https://*.intercom.io; style-src 'self' 'nonce-<your-nonce>' 'unsafe-inline' https://*.intercomcdn.com;

This approach:

• Uses nonces for better control over script security.
• Allows 'unsafe-inline' for styles but restricts it to Intercom’s trusted domains.

​@mateusz.leszkiewicz 

Thanks for the answer!

For scripts I’m fine - it works.
However I don’t think it will work for styles.

From what I know there’s no such thing as unsafe-inline for specific domain. 
When you’re adding unsafe-inline to scrtipt-src / style-src it will affect it globally.

I would love to add sha256… but it may change over time.

Anything better ?

Thanks!