What are CSP errors?

CSP is a browser security feature that controls which external resources can load — if configured too restrictively, it can prevent the Intercom Messenger, Help Center articles, images, Product Tours, and media from loading correctly.

This can disrupt key functionality and cause issues such as:

Blocked image uploads: Images cannot be loaded in Product Tours or the Messenger.
Unresponsive Product Tours: Changes made to a Product Tour fail to save.
Broken visuals: Intercom components, like logos, may appear as broken images.
Help Center issues: Articles may appear blank or partially rendered, or infinite loading spinners may occur.

Note: This article is relevant if you've installed the Intercom Messenger or any Intercom JS product on your site (including Product Tours, Surveys, Checklists, and News). If you use Intercom's standalone hosted Help Center (e.g. help.yourco.com), Intercom manages its own CSP and your site's policy does not apply there. Updating your CSP requires access to your server configuration or HTTP response headers — if you don't manage your site's infrastructure directly, share this article with your development team or IT department.

How to identify CSP errors

To confirm that CSP is causing issues with Intercom on your site, you'll need to check your browser's developer console.

Open the developer tools in your browser (typically by pressing F12 or right-clicking and selecting Inspect).
Navigate to the Console tab.
Reproduce the issue on your site, for example, by trying to upload an image or save a Product Tour.
Look for red error messages in the console indicating a CSP violation. These messages often mention blocked requests to Intercom domains (e.g., uploads.intercomcdn.com, *.intercom.io) and the specific CSP directive that caused the block, such as connect-src or img-src. Example error: Refused to load the script 'https://widget.intercom.io' because it violates the following Content Security Policy directive: "script-src 'self'".

How to resolve CSP errors

To resolve these errors, you'll need to update your site's CSP configuration to allow resources from Intercom's required domains.

1. Update your CSP directives

Locate the error directive: In the developer console error, identify which directive caused the restriction (e.g., img-src).
Allowlist Intercom domains: Add the required Intercom URLs to the relevant directives in your site's CSP configuration.

Important: You will typically need to add Intercom's domains to the following directives:

connect-src: For core functionalities.
img-src: For images and attachments.
media-src: For media resources.

The domains to add are *.intercomcdn.com, *.intercom.io, and *.intercom-chat.com (required for the Messenger's live websocket connection — not covered by the *.intercom.io wildcard). For the most up-to-date domain list, see Using Intercom with Content Security Policy.

Additionally, include intercom-sheets.com in the frame-src directive to ensure proper loading of article viewer iframes.

2. Revise security headers

Overly restrictive headers like X-Frame-Options or CSP frame-ancestors settings can also impact Intercom’s functionality. Review these settings and adjust them as needed.

3. Check network settings

Ensure your network or firewall settings allow outbound connections to Intercom's servers. You may need to ask your IT team to allowlist the necessary domains.

4. Test your changes

After updating your CSP configuration:

Reload the affected pages on your site and check if the Intercom features now function correctly.
Monitor the developer console to ensure no new CSP violations appear.
Perform a hard refresh in your browser to clear cached assets after making changes to the CSP.
If Intercom features still don't work after a hard refresh, reopen the Console tab and check for any remaining CSP violation errors. Each new error message will name the next directive or domain to add — repeat the update and test cycle until no violations appear.

Which Intercom features are affected by CSP errors?

Different Intercom features are blocked by different CSP directives. The table below maps each Intercom feature to its common symptoms, the CSP directive that blocks it, and the domains to allowlist.

Intercom feature	Symptoms	Blocked directive	Domain(s) to allowlist
Messenger (chat widget)	Widget fails to load or is invisible	script-src, connect-src	widget.intercom.io, js.intercomcdn.com, *.intercom-chat.com, api-iam.intercom.io (US), api-iam.eu.intercom.io (EU), api-iam.au.intercom.io (AU)
Help Center	Articles appear blank or fail to load	frame-src, connect-src	intercom-sheets.com, *.intercom.io
Image uploads & attachments	Images fail to upload or load broken	img-src, connect-src	uploads.intercomcdn.com, *.intercomcdn.com
Product Tours	Tours don't render or changes fail to save	script-src, connect-src, img-src	.intercom.io, .intercomcdn.com
Media (video/audio)	Media files fail to play	media-src, connect-src	*.intercomcdn.com

Tip: If you see multiple console errors at once, resolve them from the most restrictive directive first (e.g. script-src blocks more than img-src). One directive fix can sometimes resolve several symptoms.

How to update your CSP for specific Intercom features

Use Report-Only mode to audit before enforcing, then apply changes incrementally per feature.

Use Report-Only mode first

Before editing your enforced Content Security Policy (CSP) to fix Intercom issues, add a Content-Security-Policy-Report-Only header alongside your existing policy. This logs violations without blocking anything, so you can safely audit what needs to change.

Add the following Content-Security-Policy-Report-Only header to your server's HTTP response headers (alongside — not replacing — your enforced Content-Security-Policy header):

Content-Security-Policy-Report-Only:
  script-src 'self' https://widget.intercom.io https://js.intercomcdn.com;
  connect-src 'self' https://*.intercom.io https://*.intercomcdn.com
             https://*.intercom-chat.com wss://*.intercom-chat.com;
  img-src 'self' https://*.intercomcdn.com;
  media-src 'self' https://*.intercomcdn.com;
  frame-src 'self' https://intercom-sheets.com;

Apply changes incrementally

Enable Report-Only mode and reproduce the issue.
Note every blocked domain in the console output.
Add the required domain(s) to the relevant directive in your enforced policy — one directive at a time.
Re-test in Report-Only mode to confirm no new violations appear.
Promote the change to your enforced Content-Security-Policy header.
Once promoted, perform a hard refresh and confirm the Intercom feature works as expected. If a new violation appears in the console, repeat from step 1 for the new directive.

How to keep your CSP up to date

CSP configuration isn't a one-time fix. Intercom periodically updates its infrastructure and domain requirements. Follow the steps below to keep your policy current.

Monitor for new violations

Set up a CSP reporting endpoint using the report-to directive (a CSP directive that tells browsers where to send violation reports) so violations are sent to a logging service automatically — you won't have to rely on manually checking the console. Note: report-uri is deprecated in favour of report-to. When using report-to, you also need to add a companion Reporting-Endpoints HTTP response header to define the endpoint group.
Review violation reports after any Intercom update or after deploying changes to your site's infrastructure.

Stay up to date with Intercom's domain list

Bookmark the Using Intercom with Content Security Policy article and check it when Intercom releases major updates.
Subscribe to Intercom's status page to be notified of infrastructure changes that may affect required domains.

Avoid common management pitfalls

Don't use unsafe-inline or unsafe-eval as a shortcut. Adding these values to script-src disables a major class of XSS (cross-site scripting) protection and exposes your site to script injection attacks — even as a temporary measure. Instead, use nonces (cryptographic tokens added to each script tag) or hashes — Intercom supports strict CSPv3 (the third version of the CSP standard) with nonce-based policies.
Keep your CSP in version control.Track every change alongside your deployment history so you can roll back a directive change if it breaks functionality.
Test in a staging environment first. Always validate CSP changes against Intercom features in a staging or preview environment before deploying to production.

Note: If you're integrating Intercom via Google Tag Manager (GTM), ensure your GTM container's script-src and connect-src entries are also included in your policy — GTM injects scripts dynamically, which can trigger additional CSP violations separate from Intercom's own domains. If issues persist after updating these directives, deploy Intercom Messenger in a dedicated GTM tag rather than using inline scripts.

Note:CSP header changes may be cached by your CDN or browser. If you're not seeing updated policy behavior after making changes, purge your CDN cache and perform a hard refresh before testing again.

Notes:

Updating your Content Security Policy requires access to your server configuration or HTTP headers. If you don't manage your site's infrastructure directly, share this article with your development team or IT department.
When integrating Intercom Messenger via Google Tag Manager (GTM), ensure the GTM hosting region matches your Intercom workspace region. Set api_base to the endpoint for your region: api-iam.intercom.io (US), api-iam.eu.intercom.io (EU / EMEA — Europe, Middle East and Africa), or api-iam.au.intercom.io (AU).

💡Tip

Need more help? Get support from our Community Forum
Find answers and get help from Intercom Support and Community Experts

Using Intercom with Content Security Policy

Resolving Content Security Policy (CSP) errors