Update your Content Security Policy

If you use a CSP, configure it to allow Optimize to run on your site.

A Content Security Policy (CSP) defines what content the browser is allowed to load and from where. It's composed of multiple directives (e.g., script-src, frame-src) that control resource access. If your site uses a CSP, you may need to update it to ensure Optimize functions properly. If your site does not use a CSP, this content is not applicable to you.

CSP fetch directives used by Optimize

script-src

Defines valid sources for JavaScript. This value allows the use of eval(), which lets the client script load and perform tasks (e.g., apply variations):

'unsafe-eval' https://api.intellimize.co

style-src

Defines valid sources for stylesheets. This value allows Global CSS or Variation CSS to be applied:

'unsafe-inline'

connect-src

Defines valid sources for script interfaces (e.g., AJAX). This value allows Optimize to track user interactions:

https://log.intellimize.co

frame-src

Defines valid sources for nested browser contexts (i.e., iframe). This value enables variation previews and cross-origin data storage:

https://api.intellimize.co https://ACCOUNTID.intellimizeio.com

Configuring your CSP for Optimize

For each directive, your security and dev team needs to identify which scenario fits for your current CSP and then decide how best to proceed based on your business and security policies.

Scenario: Your CSP contains the directive

If your CSP includes a relevant directive (e.g., frame-src), you'd need to merge it with the required sources for Optimize.

Example:

Your frame-src directive has this value:

frame-src 'self' https://mail.google.com

The merged value could be similar to:

frame-src 'self' https://mail.google.com https://api.intellimize.co https://ACCOUNTID.intellimizeio.com

Scenario: Your CSP does not contain the directive or a default-src

In this case, omitting the new directive is preferred. Optimize will still function as there’s no restrictive fallback.

If you do decide to introduce a new fetch directive, be extremely careful to include all sources your site needs. Failure to include all sources will cause unwanted issues. For this reason, it’s not recommended, though it is more secure.

Scenario: Your CSP does not contain the directive but DOES contain a default-src

Instead of adding a new directive, you can merge the required sources into your existing default-src directive.

If you do decide to introduce a new fetch directive, be extremely careful to include all sources your site needs. Failure to include all sources will cause unwanted issues. For this reason, it’s not recommended, though it is more secure.

Example of merging with default-src:

You decide to merge script-src with default-src and your default-src value is:

default-src 'self' https://*.foo.com 

The merged value could be similar to:

default-src 'self' 'unsafe-eval' https://*.foo.com  https://api.intellimize.co

Pitfalls to avoid when adding a new directive

When you add a new directive to an existing CSP, you're specifying a new allowlist of sources (i.e., domains) that are allowed to serve that type of content. If you're not careful, this change can unintentionally block content that was previously allowed.

Before a new directive is added, content might be allowed because:

• No directive — there was no CSP directive for that type of content
• Fallback — it was allowed via the fallback default-src directive

If either is true and you only add the Optimize-specific value to a new directive, the original content will now be blocked. That's because an explicit directive overrides the fallback or absence of one.

Example:

Suppose your current CSP looks like this:

frame-ancestors 'self' https://*.foo.com
frame-src       'self' https://mail.google.com

To add Optimize support, it might look like you only need to add new directives, like the following. However, doing this will likely block a number of things that used to be allowed (e.g., JS, CSS, AJAX content).

# DO NOT DO THIS
frame-ancestors 'self' https://*.foo.com
frame-src       'self' https://mail.google.com https://api.intellimize.co https://CUSTOMER_ID.intellimizeio.com
script-src      'unsafe-eval' 'self' https://api.intellimize.co
style-src       'unsafe-inline'
connect-src     https://log.intellimize.co

Best practices:

Instead of just adding the Optimize-specific values, make sure to:

• Include all necessary sources for each new directive
• Merge existing sources with new ones to maintain functionality
• Tailor the policy to your organization’s specific requirements

Validate your CSP before enforcing it

There are multiple ways to validate your CSP. We recommend using “report only” mode, using the browser console to check for errors, and setting up reporting endpoints. 

1. Deploy your CSP in report only mode in a staging environment
2. Run exhaustive site tests in staging — ensure everything works and check the browser console for errors
3. Deploy the CSP to production in report only mode — once confident, apply the CSP to production in report only mode
4. Run exhaustive site tests in production — test your live site and check for errors in the browser console
5. Flip the switch — once validated, change your CSP from “report only” to enforcement mode and test again

Using report only mode

If you're using a CSP header (not the <meta> element), you can enable report only mode by changing the header from Content-Security-Policy to Content-Security-Policy-Report-Only (learn more). This lets you detect and debug violations without actually blocking any content.

In the browser console, these violations will appear with a [Report Only] prefix.

To monitor violations across users, you can specify a report-uri. This sends CSP violation data to an endpoint of your choice, allowing broader visibility into issues encountered by anyone visiting your site.

Using the browser console

To validate your CSP locally, open your browser’s developer tools and view the console. Any CSP violations will appear there as error messages. Review the Google Chrome console documentation for info on how to access and use it.

Moving to enforcement mode

Once your CSP has been validated, switch the header back to Content-Security-Policy to begin enforcement. It’s a good idea to keep the report-uri in place so you can continue monitoring for unexpected violations in production.