The Content Security Policy (CSP) response header helps you reduce XSS risks on modern browsers by declaring what dynamic resources are allowed to load via a HTTP Header, thereby protecting your solution from a range of vulnerability attacks.
By default, Temenos Journey Manager has strict CSP settings configured. Occasionally you need to include a capability or 3rd party service in your forms that require changes to the default CSP settings. This article describes how to manage these settings in Journey Manager in order to allow your solution to operate as expected, yet still maintain a strong CSP configuration.
Step-by-step guide
CSP configurations can be modified at a system wide level, and/or at the organization level. The following sections describe how to achieve each of these configuration options.
System Wide Settings
- As a global administrator, in Journey Manager go to the Services menu and select All Services.
- Filter the list to display only services of type Form Submission Access Controller - there should only be one item of this type.
- Open the service and on the Parameters Edit page modify the Form CSP Header Value as required and Save.
Organization Level Settings
- As an organization administrator, in Journey Manager go to the Forms menu and select Organizations.
- Open your organization and go to the Security tab.
- Under Forms Content Security Policy (CSP), select the Override System Defaults checkbox then Save.
- Modify the value of CSP Security Header as required and Save.
LinkedIn Example
The LinkedIn SDK requires a JavaScript library to be loaded from their remote server. The default CSP settings are usually something like:
script-src 'self'; object-src 'none'
These settings permit scripts to be loaded from the same server, but no other. To permit the remote LinkedIn JavaScript file to load we must modify these setting to allow JavaScript sources from the relevant LinkedIn domains as follows:
script-src 'self' https://platform.linkedin.com https://www.linkedin.com 'unsafe-inline'; object-src 'none';
Due to the way the LinkedIn integration uses inline JavaScript, we need to add the 'unsafe-inline' directive.
Note that when we relax these settings, we are only adding known and trusted domains to the configuration, as opposed to using wildcards which could compromise this security layer.