Skip to main content


Optimizely Knowledge Base

Update your site's Content Security Policies (CSP) in Optimizely Classic

  • Replace the deprecated X-Frame-Options HTTP header with its successor, Content Security Policies
  • Set Content Security Policies (CSP) in a way that allows for your site to load in Optimizely's Editor

Having trouble loading your page into the Optimizely Editor? 

Many sites protect visitors from cross-site scripting (XSS), clickjacking, and other code injection attacks by adding an X-Frame-Options header. However, this can prevent Optimizely from loading your page into Editor. It also blocks Optimizely from running parts of the snippet on your pages or sending tracking information back to our servers.

Switch to the newer Content Security Policy (CSP) header to run Optimizely and keep your customers safe and sound.

Switch to Content Security Policies (CSP)

X-Frame-Options is a deprecated web standard that has been succeeded by Content Security Policies, which allows for greater customization. Make the switch so you can keep your users safe, while gaining the ability to whitelist Optimizely and work with pages in the Editor.

Replace your existing X-Frame-Options HTTP response header with the following three Content Security Policy HTTP headers for the same protection for your users: 

Content-Security-Policy: "frame-src 'self' *"
X-Content-Security-Policy: "frame-src 'self' *"
X-WebKit-CSP: "frame-src 'self' *"

Now your browser will allow your site and Optimizely to load your pages in an iframe, while blocking attempts from all other parties.

The CSP whitelist isn't limited to only one domain. Feel free to add domains of other sites that you think should be able to embed your pages, separated by a space.

Enable these features in CSP if you're experiencing issues

Most sites implement Content Security Policies to block everything that can potentially expose visitors to harm -- and then explicitly whitelist features that are needed.

You'll need to enable default, script, and style features for Optimizely to work.

1. Default

Update your site to inform your visitors' browsers that Optimizely is a trusted source for JavaScript, Stylesheets, AJAX requests (e.g. for event tracking or effective Audience targeting), and embedding your pages in the Optimizely Editor.

Add Optimizely's subdomains to the Default whitelist across all categories of CSP, like so:

Content-Security-Policy: "default-src 'self' *"
X-Content-Security-Policy: "default-src 'self' *"
X-WebKit-CSP: "default-src 'self' *"

2. Script

Some of Optimizely's functionality on your site depends on:

  • evaluating text strings as executable JavaScript 

  • running inline JavaScript

These practices are blocked by default.

You'll need to whitelist them separately by adding the following rule:

script-src 'unsafe-inline' 'unsafe-eval'

3. Style

Optimizely allows you to change the appearance of elements on your site with the Editor, without releasing code to your site.

For this to work, inline style changes must be enabled. Add the following rule:

style-src 'unsafe-inline'

Example of a complete CSP directive

Once you've gone through the steps above, the set of directives in your Content Security Policies may look something like this:

Content-Security-Policy: "default-src 'self' *; script-src 'unsafe-inline' 'unsafe-eval'; style-src 'unsafe-inline'"
X-Content-Security-Policy: "default-src 'self' *; script-src 'unsafe-inline' 'unsafe-eval'; style-src 'unsafe-inline'"
X-WebKit-CSP: "default-src 'self' *; script-src 'unsafe-inline' 'unsafe-eval'; style-src 'unsafe-inline'"

Since you're likely to use other third-party tools in addition to Optimizely, your rules might look different. Make sure to test them thoroughly before going live with these restrictions.

You can soft-launch your changes in report-only mode so that the restrictions don't affect your visitors, but violations are collected (e.g. via so you can adapt and fine-tune your CSP.