Skip to main content
Answered

Is there a way to serve Intercom with Content Security Policy without style-src: 'unsafe-inline'


We would need to add Content Security Policy to our application. I saw this article on Intercom Help. There it is stated to use 'unsafe-inline' but I am wondering is there a way not to use it, since we would like avoid that in our policy?

Best answer by mateusz.leszkiewicz

Hi ​@MattWD

You're correct that 'unsafe-inline' applies globally and cannot be restricted to a specific domain like Intercom. While 'sha256-<hash>' is a better alternative for inline styles, its dynamic nature can indeed pose challenges if the styles change frequently.

Here are some additional thoughts and strategies you might find useful:

1. Dynamic Hash Automation

If you control the server setup and can dynamically generate the CSP header, you could:

  • Monitor the inline styles injected by Intercom.
  • Dynamically compute their hash at runtime.
  • Add the computed hash to your style-src directive.

This approach requires server-side scripting and might be complex to implement, but it avoids 'unsafe-inline'.

2. Proxy Inline Styles

Another workaround is intercepting Intercom's inline styles via a CSP-compatible middleware that rewrites them into external stylesheets hosted on your server. Then, whitelist this external stylesheet in your CSP.

Challenges:

  • This requires monitoring changes to the injected styles.
  • It adds maintenance overhead.

3. Use an Allowlist for Trusted Intercom Styles

If you find that Intercom's styles remain stable over time, you can curate an allowlist of hashes for all currently injected styles. Add these hashes to your CSP.

Example:

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

Caveat: Maintenance is required if Intercom updates their injected styles.

4. Request Intercom to Support Nonces

Since Intercom doesn’t natively support nonce, you could escalate this as a feature request to their support. It’s a known limitation, and many other third-party providers already offer this functionality.

Nonces would allow injected styles to be safely tied to your CSP configuration, ensuring security without relying on 'unsafe-inline'.

Pragmatic Recommendation

If the above approaches aren't feasible:

  • Use 'unsafe-inline' temporarily but restrict it to the style-src directive.
  • Monitor the Intercom roadmap for updates or engage their support for best practices.

Example CSP:

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

This strikes a balance between functionality and security while awaiting a more robust solution.

View original

  • Active User
  • June 27, 2022

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."


  • New Participant
  • June 27, 2022

@evan p​ 

Thanks for your reply 👍


@Evan P Hello Evan,

Any progress on using Intercom with CSP?

 

Pascal


mateusz.leszkiewicz
Intercom Team
Forum|alt.badge.img+5

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.


Jacob Cox
Intercom Team
Forum|alt.badge.img+5
  • Sr. Technical Support Engineer
  • April 20, 2024

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?


Erin
Forum|alt.badge.img+1
  • Active User
  • November 12, 2024

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


  • New Participant
  • November 15, 2024

+1


  • New Participant
  • November 20, 2024

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.


mateusz.leszkiewicz
Intercom Team
Forum|alt.badge.img+5

@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.


  • New Participant
  • November 29, 2024

@mateusz.leszkiewicz 

How should I read this part:
 

mateusz.leszkiewicz wrote:

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.


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!


mateusz.leszkiewicz
Intercom Team
Forum|alt.badge.img+5

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.

  • New Participant
  • November 29, 2024

@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!


mateusz.leszkiewicz
Intercom Team
Forum|alt.badge.img+5

Hi ​@MattWD

You're correct that 'unsafe-inline' applies globally and cannot be restricted to a specific domain like Intercom. While 'sha256-<hash>' is a better alternative for inline styles, its dynamic nature can indeed pose challenges if the styles change frequently.

Here are some additional thoughts and strategies you might find useful:

1. Dynamic Hash Automation

If you control the server setup and can dynamically generate the CSP header, you could:

  • Monitor the inline styles injected by Intercom.
  • Dynamically compute their hash at runtime.
  • Add the computed hash to your style-src directive.

This approach requires server-side scripting and might be complex to implement, but it avoids 'unsafe-inline'.

2. Proxy Inline Styles

Another workaround is intercepting Intercom's inline styles via a CSP-compatible middleware that rewrites them into external stylesheets hosted on your server. Then, whitelist this external stylesheet in your CSP.

Challenges:

  • This requires monitoring changes to the injected styles.
  • It adds maintenance overhead.

3. Use an Allowlist for Trusted Intercom Styles

If you find that Intercom's styles remain stable over time, you can curate an allowlist of hashes for all currently injected styles. Add these hashes to your CSP.

Example:

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

Caveat: Maintenance is required if Intercom updates their injected styles.

4. Request Intercom to Support Nonces

Since Intercom doesn’t natively support nonce, you could escalate this as a feature request to their support. It’s a known limitation, and many other third-party providers already offer this functionality.

Nonces would allow injected styles to be safely tied to your CSP configuration, ensuring security without relying on 'unsafe-inline'.

Pragmatic Recommendation

If the above approaches aren't feasible:

  • Use 'unsafe-inline' temporarily but restrict it to the style-src directive.
  • Monitor the Intercom roadmap for updates or engage their support for best practices.

Example CSP:

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

This strikes a balance between functionality and security while awaiting a more robust solution.


Hi ​@mateusz.leszkiewicz

Thanks for your effort (although it looks a lot like AI generated content…). Perhaps usefull for some, I just felt need to stipulate that the issue itself is not solved and (for us) the workarounds do not work. 
Any update on if / when style-src can be used without unsafe-inline? Thanks!


  • New Participant
  • December 26, 2024

@mateusz.leszkiewicz we are waiting for you to act on 4.


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings