Standard Form Space Properties

   Journey Manager (JM) The transaction engine for the platform. |   System Manager / DevOps |   21.11 This feature was updated in 21.11.

Each form space has a number of predefined properties that allow you to customize a form space without any extra development efforts. For example, you can easily improve form space access security by using the CORS headers. Manager allows you to edit form space's properties, so you can implement additional customization as required.

Some properties are straight-forward but some require more understanding, so we describe them in details below.

• Cache Headers
• CORS Headers
• Security Headers
• X-Frame-Options

Cache Headers

The cache HTTP header allows you to set the following values:

• Pragma
• Cache-Control
• Expires

For more information, see Cache-Control.

The example of Cache Headers configuration is shown below:

Pragma: no-cache
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0, private
Expires: 1

CORS Headers

Manager evaluates the following conditions of a request and if they all match, then the content of CORS_HEADERS is applied to a response.

• ApplyCORSHeaders - if set to true, Manager applies CORS HEADERS to the request as described below. Otherwise, if set to false, this functionality is disabled.
• CORSApprovedOrigins - a list of approved origins, which are used to validate the origin on a request. If an approved origin matches the ${request-origin}, it is replaced with the provided origin.  |  19.05 This feature was introduced in 19.05.
• ExcludedCORSPaths - a comma-separated list of paths that Manager uses to match any part of an endpoint URL of the request. If the match exists, Manager excludes it from having the headers applied. For example, if you have "ExcludedCORSPaths":"/servlet" configured, then all requests from the /my-site/servlet/FormDynamicDataServlet endpoint will be excluded and the headers won't be applied. This is because /my-site/servlet/FormDynamicDataServlet contains /servlet.
  Warning

  If you have an empty ExcludedCORSPaths condition, for example, "ExcludedCORSPaths":"", Manager won't apply CORS Headers to the response, regardless of any other conditions. This behavior will be fixed in  |  23.04This feature will be introduced in 23.04

The Cross-Origin-Resource-SharingCross-Origin Resource Sharing (CORS) is a mechanism that uses additional HTTP headers to tell a browser to let a web application running at one origin (domain) have permission to access selected resources from a server at a different origin. A web application executes a cross-origin HTTP request when it requests a resource that has a different origin (domain, protocol, and port) than its own origin. (CORS) security HTTP header allows you to set various parameters to a response. Here we only list the most common ones that are pre-configured in a standard form space:

• Access-Control-Allow-Origin
• Access-Control-Allow-Methods
• Access-Control-Allow-Credentials
• Access-Control-Max-Age
• Content-Security-Policy

For more information, see Cross-Origin Resource Sharing (CORS).

The example of CORS configuration is shown below:

{
	"ApplyCORSHeaders":"true",
	"CORSApprovedOrigins":"test-cors.org,avoka.com,temenos.com", 
	"ExcludedCORSPaths":"/secure/servlet,/secure/app,/cache",
	"CORS_HEADERS":{
		"Access-Control-Allow-Origin":"${request-origin}",
		"Access-Control-Allow-Methods":"POST,GET",
		"Access-Control-Allow-Credentials":"true",
		"Access-Control-Max-Age":"86400",
		"Content-Security-Policy":"script-src 'self' ${cdn} 'unsafe-inline'; connect-src 'self'; object-src 'none'
	}
}

Security Headers

The Content Security PolicyContent Security Policy (CSP) is a computer security standard introduced to prevent cross-site scripting (XSS), clickjacking and other code injection attacks resulting from execution of malicious content in the trusted web page context. CSP provides a standard method for website owners to declare approved origins of content that browsers should be allowed to load on that website—covered types are JavaScript, CSS, HTML frames, web workers, fonts, images, embeddable objects such as Java applets, ActiveX, audio and video files, and other HTML5 features. For more information, see https://www.w3.org/TR/CSP/ (CSP) security HTTP header improves overall forms' security. It is applied to all form's resources that are passed via each form space. If it is not set, the Form CSP Header Value parameter of the Form Submission Access Controller server is used as the default.  |   18.11 This feature was introduced in 18.11.

The 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.

For more information, see Content Security Policy (CSP).

The example of the CSP response header is shown below:

Content-Security-Policy: script-src 'self' 'unsafe-eval'; object-src 'none'; connect-src 'self' 
X-Frame-Opticns: SAMEORIGIN 
X-Content-Type-Options: nosniff 
X-XSS-Prctection: l; mode=block

By default, Manager has strict CSP settings configured. Occasionally, you need to include a capability or a 3rd party service in your forms that require changes to the default CSP settings. You can configure the following settings in Manager in order to allow your solution to operate as expected yet still maintain a strong CSP configuration.

To configure CSP:

System Wide Settings

1. Log in to Manager as a Global Administrator.
2. Select Services > All Services.
3. Select Form Submission Access Controller from the Type dropdown list. There should be only one item of this type.
4. Click the service and select the Parameters Edit tab.
5. Modify a CSP in the Form CSP Header Value field as required and click Save. For more information, see configure service parameters edit.

Organization Level Settings

1. Log in to Manager as an Organization Administrator.
2. Select Forms > Organizations.
3. Find your organization and select the Security tab.
4. Under Forms Content Security Policy (CSP), select the Override System Defaults checkbox and click Save.
5. Modify the value of Organization CSP Header as required and click Save . For more information, see configure organization security.

LinkedIn Example

Let's illustrate how to use these headers with a simple 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';

Because the LinkedIn integration uses inline JavaScript, we need to add the 'unsafe-inline' directive. When you want torelax these settings, you have to add only known and trusted domains to the configuration, as opposed to using wildcards which could compromise this security layer.

X-Frame-Options

The X-Frame-OptionsX-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame>, <iframe>, <embed> or <object> . Sites can use this to avoid clickjacking attacks, by ensuring that their content is not embedded into other sites. HTTP header improves overall forms' security. It is applied to all form's resources that are passed via each form space. The X-Frame-Options include:

• NONE
• SAMEORIGIN - the page can only be displayed in a frame on the same origin as the page itself
• ALLOW-FROM URI - the page can only be displayed in a frame on the specified origin, for example www.example.com
• blank - no X-Frame-Options header will be set

For more information, see X-Frame-Options.

Next, learn how to configure form space properties.