Adobe Experience Platform Launch is being rebranded as a suite of data collection technologies in Experience Platform. These changes will be rolling out across all product documentation in the coming weeks. Please refer to the following document for a consolidated reference of the terminology changes.
A Content Security Policy (CSP) is a security feature that helps prevent cross-site scripting attacks (XSS). This happens when the browser is tricked into running malicious content that appears to come from a trusted source, but is really coming from somewhere else. CSPs allow the browser (on behalf of the user) to verify that the script is actually coming from a trusted source.
CSPs are implemented by adding a
Content-Security-Policy HTTP header to your server responses, or by adding a configured
<meta> element in the
<head> section of your HTML files.
For more detailed information on CSP, refer to the MDN web docs.
As a tag management system, Adobe Experience Platform Launch is designed to dynamically load scripts on your website. A default CSP blocks these dynamically loaded scripts due to potential security problems. This document provides guidance on how to configure your CSP to allow dynamically loaded scripts from Platform Launch.
If you want Adobe Experience Platform Launch to work with your CSP, there are two main challenges to overcome:
Increased security comes at the price of increasing the amount of work on your part. If you want to use Platform Launch and have a CSP in place, you have to address both of these issues without incorrectly marking other scripts as safe. The rest of this document provides guidance on how to achieve this.
When using a CSP, you must include any trusted domains within the value of the
Content-Security-Policy header. The value you must provide for Platform Launch will vary depending on the type of hosting you are using.
If you are self-hosting your library, then the source for your build is probably your own domain. You can specify that the host domain is a safe source by using the following configuration:
Content-Security-Policy: script-src 'self'
<meta http-equiv="Content-Security-Policy" content="script-src 'self'">
If you are using an Adobe-managed host, then your build is maintained on
assets.adobedtm.com. You should specify
self as a safe domain so you don’t break any scripts that you are already loading, but you also need
assets.adobedtm.com to be listed as safe or your Platform Launch library won’t load on the page. In this case, you should use the following configuration:
Content-Security-Policy: script-src 'self' assets.adobedtm.com
There is a very important prerequisite: You must load the Platform Launch library asynchronously. This does not work with a synchronous load of the Platform Launch library (which results in console errors and rules not executing properly).
<meta http-equiv="Content-Security-Policy" content="script-src 'self' assets.adobedtm.com">
You should specify
self as a safe domain so that any scripts that you are already loading continue to work, but you also need
assets.adobedtm.com to be listed as safe or your library build won’t load on the page.
CSP disallows inline scripts by default, and therefore must be manually configured to allow them. You have two options to allow inline scripts:
The CSP specification has details for a third option using hashes, but this approach is not feasible to use with tag management systems like Platform Launch. For more information on the limitations of using hashes in Platform Launch, see the Subresource Integrity (SRI) guide.
This method involves generating a cryptographic nonce and adding it to your CSP and every inline script on your site. When the browser receives an instruction to load an inline script with a nonce on it, the browser compares the nonce value to what is contained within the CSP header. If it matches, the script is loaded. This nonce should be changed with each new page load.
In order to use this method, you must load the build asynchronously. This does not work when loading the build synchronously, which results in console errors and rules not executing properly. See the guide on asynchronous deployment for more information.
The examples below show how you can add your nonce to the CSP configuration for an Adobe-managed host. If you are using self-hosting, you can exclude
Content-Security-Policy: script-src 'self' assets.adobedtm.com 'nonce-2726c7f26c'
<meta http-equiv="Content-Security-Policy" content="script-src 'self' assets.adobedtm.com 'nonce-2726c7f26c'">
Once you configure your header or HTML tag, must then tell Platform Launch where to find the nonce when loading an inline script. For Platform Launch to use the nonce when loading the script, you must:
The above process only handles loading your custom code, not what that custom code does. If an inline script contains custom code that is not compliant with your CSP, the CSP takes precedence. For example, if you use custom code to load an inline script by appending it to the DOM, Platform Launch cannot add the nonce correctly, so that particular custom code action will not work as expected.
If using nonces does not work for you, you can configure your CSP to allow all inline scripts. This is the least secure option, but is also easier to implement and maintain.
The examples below show how can allow all inline scripts in the CSP header.
Use the following configurations if you are using self-hosting:
Content-Security-Policy: script-src 'self' 'unsafe-inline'
<meta http-equiv="Content-Security-Policy" content="script-src 'self' 'unsafe-inline'">
Use the following configurations if you are using Adobe-managed hosting:
Content-Security-Policy: script-src 'self' assets.adobedtm.com 'unsafe-inline'
<meta http-equiv="Content-Security-Policy" content="script-src 'self' assets.adobedtm.com 'unsafe-inline'">
By reading this document, you should now understand how to configure your CSP header to accept the Platform Launch library file and inline scripts.
As an additional security measure, you may also opt to use Subresource Integrity (SRI) to validate fetched library builds. However, this feature has some major limitations when used with tag management systems like Platform Launch. See the guide on SRI compatibility in Platform Launch for more information.