- 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 X Visual 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.
For this reason, you may need to update your site to include Content Security Policy (CSP) header in order to run Optimizely and keep your customers safe from outside attacks.
Implement Content Security Policies (CSP) in Optimizely X
X-Frame-Options is a deprecated web standard that has been succeeded by Content Security Policies, which allows for greater customization, including the ability to whitelist Optimizely and work with pages in the Editor.
For Optimizely X, add the following directives to the CSP header for your pages:
frame-src https://app.optimizely.com https://a[your-account-id-here].cdn.optimizely.com; script-src 'self' https://*.optimizely.com https://optimizely.s3.amazonaws.com https://cdn-assets-prod.s3.amazonaws.com 'nonce-[your-nonce-value]' 'strict-dynamic'; connect-src https://logx.optimizely.com https://*.optimizely.com; img-src https://cdn.optimizely.com; style-src 'unsafe-inline';
How the CSP directives work
Each of the five directives in the CSP policy has a specific purpose:
frame-src https://app.optimizely.com https://a[your-account-id-here].cdn.optimizely.com
This enables your page to load in Optimizely’s Visual Editor and enables cross-domain behavioral targeting. If you don’t need cross-domain behavioral targeting, you can omit
a[your-account-id-here].cdn.optimizely.com from this string.
script-src 'self' https://*.optimizely.com https://optimizely.s3.amazonaws.com https://cdn-assets-prod.s3.amazonaws.com 'nonce-[your-nonce-value]' 'strict-dynamic';
This enables the Optimizely client script, the preview mode client, and Optimizely geotargeting. In browsers which support 'strict-dynamic' (Content Security Policy Level 3), it's only necessary to apply the "nonce" value to the Optimizely snippet script tag. If you only need to support such browsers, the directive can be simplified to:
script-src 'nonce-[your-nonce-value]' 'strict-dynamic'
strict-dynamic for more information about backwards compatibility in
connect-src https://logx.optimizely.com https://*.optimizely.com
This line enables the Optimizely X client to log events.
This allows the Optimizely client to load images that have been uploaded using the Visual Editor.
This is required for experiment CSS changes to be applied. It is also required to avoid a jQuery feature detection error for any jQuery versions below 1.8.3.
Now your browser will allow your site and Optimizely to load your pages in an iframe, while blocking attempts from all other parties.
Features that require explicit whitelisting
Some features will not be available in Optimizely X unless
unsafe-eval' is included in your policy's
optimizely_editor=true query param).
To enable these features, simply add this directive to your CSP header:
Experiment custom code and conditional activation code are not checked for syntax in the UI. Use this tool to check the syntax of your custom code.
Example of a complete CSP policy
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 'none'; frame-src https://app.optimizely.com https://a[your-account-id-here].cdn.optimizely.com; script-src 'self' https://*.optimizely.com https://optimizely.s3.amazonaws.com https://cdn-assets-prod.s3.amazonaws.com; connect-src https://*.optimizely.com; img-src https://app.optimizely.com https://cdn.optimizely.com; 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 report-uri.io) so you can adapt and fine-tune your CSP.
Occasionally, we'll get a customer asking: "how do I whitelist Optimizely's app server IPs for my Content Security Policy" or "What IPs will a Full Stack/Mobile webhook POST originate from so I can avoid having an insecure webhook handler"
These people are operating on the assumption that we manage our own app servers, and have a range of external IPs that an Optimizely server might belong to. That assumption is wrong. Here's why: https://cloud.google.com/appengine/kb/#static-ip
This also affects Full Stack/Mobile Webhook POSTs. Since a webhook POST would still originate from our app servers (familiarize yourself with webhooks here: https://developers.optimizely.com/x/...=node#webhooks).
For the Content-Security Policy, you probably all know the answer. They need to whitelist the domain instead of IP addresses. They can allow all traffic from `*.optimizely.com`
For webhooks, they'll need to read the `X-Hub-Signature` header of our POSTs, which contains a secret key they can use to validate the request. You can read about that here: https://developers.optimizely.com/x/...uring-webhooks