Content Security Policies (CSPs) add an extra layer of security by helping detect and prevent certain types of attacks, such as Cross-Site Scripting (XSS) and data injection.
To enable CSP, you would need to configure your web server to return the Content-Security-Policy HTTP header. Alternatively, the <meta> element can be used to set a CSP, for example:
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; child-src 'none';">If you are using a CSP, certain allowances may be needed to ensure optimal performance for the Osano Consent Manager script. If you are not using a CSP, these changes are not required.
Web Workers: Osano uses web workers for script and cookie blocking, so allowing web workers in your CSP is necessary for best performance.
Blob URIs: To support blob URIs used by Osano, add blob: as an allowed source in your CSP.
Example: (Example purposes only - must be configured to meet your CSP needs)
<meta http-equiv="Content-Security-Policy" content="style-src 'unsafe-inline' http: https: 'self'; script-src blob: http: https: 'self';">Nonce Support: For enhanced security, you can use a nonce to allow specific inline scripts while restricting others. To implement nonce-based CSP for Osano, assign a unique nonce attribute to inline scripts and include that nonce in the CSP.
Example with Nonce:(Example purposes only - must be configured to meet your CSP needs)
Replace <unique-nonce> with a generated value for each request.
<meta http-equiv="Content-Security-Policy" content="script-src 'self' https://*.osano.com 'nonce-<unique-nonce>';"><script nonce="<unique-nonce>">/* Your Osano script here */</script>Allow Specific Domains: To ensure full functionality, add allowances for style-src, script-src, frame-src, connect-src, and worker-src for the osano.com domain. You can set *.osano.com as an allowed domain or specify the following subdomains:
consent.api.osano.com
tattle.api.osano.com
cmp.osano.com
disclosure.api.osano.com
A: No, SHA hashes are not supported as a CSP solution for the osano.js file.
This is due to a couple of key reasons:
The script is dynamic and changes frequentlyThe osano.js file can change each time you publish updates to your configuration or when new versions of the CMP are released. This would invalidate any previously generated SHA hash.
The script varies by user locationOsano may serve different versions of the script depending on the user’s geographic location. Because of this, a single SHA hash would not consistently match the delivered file.
For these reasons, we recommend using domain-based allowances or nonce-based approaches when configuring your CSP for Osano.