What are Content Security Policies?
Content security policies are a modern security feature, which tell the browser which domains are allowed to operate on your website, and what permissions they're allowed.
They are specified either on the Request Headers (most common) for the document, or by using the Meta Tag. e.g.:
HTTP Header example:
Content-Security-Policy: default-src 'self'; img-src https://*; child-src 'none';
Meta Tag example:
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';" />
Adding Webtrends Optimize to your Content Security Policies
Use of 'all' and default
Many websites opt to use "all" and default as an option for some rules, in which case you may not need to specify our domain explicitly. For example, default-src is an acceptable fallback for listing all of script-src, connect-src, style-src and img-src.
Webtrends Optimize has 2 domains from which we operate, depending on what you're doing with us. These are:
*.webtrends-optimize.com- for core services*.webtrends-optimize.workers.dev- for custom libraries and geolocation services
Permissions required for core services
These should be added to your existing rules, which will likely include your own domains, services, web analytics services, ad tracking, etc.
script-src: 'unsafe-eval' 'unsafe-inline' *.webtrends-optimize.com
connect-src: *.webtrends-optimize.com
style-src: 'unsafe-inline' *.webtrends-optimize.com
img-src: *.webtrends-optimize.com
frame-src: c.webtrends-optimize.com
Note: This does not include support for Geolocation lookup services, Social Proofing, Recommendations and other custom services we may build for you - see below in that instance.
Permissions required for all services
These should be added to your existing rules, which will likely include your own domains, services, web analytics services, ad tracking, etc.
script-src: 'unsafe-eval' 'unsafe-inline' *.webtrends-optimize.com *.webtrends-optimize.workers.dev
connect-src: *.webtrends-optimize.com *.webtrends-optimize.workers.dev
style-src: 'unsafe-inline' *.webtrends-optimize.com *.webtrends-optimize.workers.dev
img-src: *.webtrends-optimize.com *.webtrends-optimize.workers.dev
frame-src: c.webtrends-optimize.com
Simpler permissions listing
Warning: Poorer security
While many websites use default-src, it does carry poorer security / more risk than the more granular approach listed above. We list the option here given how many of our customers use it.
If you use default-src rules, you can add us into these directly too.
default-src: 'unsafe-eval' 'unsafe-inline' *.webtrends-optimize.com, *.webtrends-optimize.workers.dev
Granular permissions listing
If you don't want to use wildcards for domains, consider the following CSP rules:
For core services
script-src: 'unsafe-eval' 'unsafe-inline' c.webtrends-optimize.com ots.webtrends-optimize.com pat.webtrends-optimize.com collect.webtrends-optimize.com
connect-src: c.webtrends-optimize.com ots.webtrends-optimize.com pat.webtrends-optimize.com collect.webtrends-optimize.com
style-src: 'unsafe-inline' c.webtrends-optimize.com ots.webtrends-optimize.com pat.webtrends-optimize.com collect.webtrends-optimize.com
img-src: c.webtrends-optimize.com ots.webtrends-optimize.com pat.webtrends-optimize.com collect.webtrends-optimize.com
frame-src: c.webtrends-optimize.com
For all services
script-src: 'unsafe-eval' 'unsafe-inline' c.webtrends-optimize.com ots.webtrends-optimize.com pat.webtrends-optimize.com collect.webtrends-optimize.com *.webtrends-optimize.workers.dev
connect-src: c.webtrends-optimize.com ots.webtrends-optimize.com pat.webtrends-optimize.com collect.webtrends-optimize.com *.webtrends-optimize.workers.dev
style-src: 'unsafe-inline' c.webtrends-optimize.com ots.webtrends-optimize.com pat.webtrends-optimize.com collect.webtrends-optimize.com *.webtrends-optimize.workers.dev
img-src: c.webtrends-optimize.com ots.webtrends-optimize.com pat.webtrends-optimize.com collect.webtrends-optimize.com *.webtrends-optimize.workers.dev
frame-src: c.webtrends-optimize.com
What are each of these domains?
c.webtrends-optimize.com - our CDN, used for all scripts, imagery, etc.
pat.webtrends-optimize.com - our newer test decision engine.
collect.webtrends-optimize.com - our newer data collection service.
ots.webtrends-optimize.com - our legacy test decision and data collection engine.
The need for keywords
There are a few CSP keywords that we need to include. The reasons for them are found below.
Unsafe-eval
Our tag ships code backwards and forwards from OTS / PAT services, when rendering experiences on the page. This code is shipped as a string, and so Eval is needed to parse this response.
Is eval really unsafe?
No more than anything else, nowadays. There was a time where it was looked-down on, but in reality any MITM attack could choose to target any resource, such as the page itself, your GTM container, or anything else they choose. There is no "need" to have eval to execute malicious code in this scenario, as once feared in 2000-2010.
Unsafe-inline
We write style blocks to the page, as opposed to remote stylesheets, as common practise for things like masking the page temporarily and transformations for your experiments.
Unsafe-inline is for CSS, and is required for these reasons.