- Optimizely X Web Experimentation
- Optimizely X Web Personalization
- Optimizely X Web Recommendations
THIS ARTICLE WILL HELP YOU:
- 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 strings to your CSP header value:
frame-src app.optimizely.com a[your-account-id-here].cdn.optimizely.com script-src 'self' *.optimizely.com optimizely.s3.amazonaws.com cdn-assets-prod.s3.amazonaws.com connect-src logx.optimizely.com *.optimizely.com img-src cdn.optimizely.com style-src 'unsafe-inline'
If you need to implement CSP in Optimizely Classic, see this article instead.
How the CSP headers work
Each of the five lines contained in the CSP header has a specific purpose:
frame-src app.optimizely.com 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' *.optimizely.com optimizely.s3.amazonaws.com cdn-assets-prod.s3.amazonaws.com
This enables the Optimizely client script, the preview mode client, and Optimizely geotargeting.
connect-src logx.optimizely.com *.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
optimizely_editor=true query param).
To enable these features, simply add this line 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 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 'none' frame-src app.optimizely.com a[your-account-id-here].cdn.optimizely.com script-src 'self' *.optimizely.com optimizely.s3.amazonaws.com cdn-assets-prod.s3.amazonaws.com connect-src *.optimizely.com img-src app.optimizely.com 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 Fullstack/Mobile Webhook POST originate from so I can avoid having an insecure webhook"
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 Fullstack/Mobile Webhook POSTs. Since a Webhook POST would still originate from our appservers (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