Edit on Github

HTTP Header Security

The HTTP Header Security mechanism allows you to add security-related response headers which enable browser-side security mechanisms.

What are the headers supposed to be?

This section briefly describes the purpose of the headers. You can find more information about the XSS Protection, Content Security Policy as well as Content-Type Options header in Mozilla’s Developer Guide.

XSS Protection

If the XSS Protection header is enabled some cross-site scripting (XSS) attacks are detected, and the malicious parts of the page are either sanitized, or the rendering of the page is blocked entirely.

Content Security Policy

The Content Security Policy is a mighty tool to prevent cross-site scripting and code injection attacks.

It is a common practice to extend the Camunda Platform web applications by custom scripts & forms. To ensure that these user customizations work without any problems, by default, the Content Security Policy is configured very lax. It is highly recommended to strengthen the default policy based on your requirements.

Default Policy

For the default policy, only the base-uri directive is set to 'self' which restricts the HTML Base Tag to point to the same-origin.

The header value of the default policy looks as follows:

base-uri 'self'

Strengthen the Default Policy

We encourage you to use a stricter Content Security Policy than the default policy to mitigate attacks. This section describes how to configure several directives more strict and explains the resulting impact:

base-uri 'self'
- The URI of the HTML Base Tag must not point to a cross-origin
default-src 'self' 'unsafe-inline' 'unsafe-eval'
- Resources (e. g. scripts, styles, fonts, etc.) must not point to a cross-origin
- Inline styles/scripts must be allowed since the web applications make use of it
- JavaScript’s eval(…) calls must be allowed to execute cam-script in Tasklist
img-src 'self' data:
- Images must not point to a cross-origin
- Data URIs are allowed since the web applications make use of it
block-all-mixed-content
- When accessed via HTTPS, all resources loaded via HTTP are blocked
- Mixed content is allowed when the site is accessed via HTTP
form-action 'self'
- A form must not be submitted against a cross-origin
- JavaScript in the action attribute of a form is not executed
frame-ancestors 'none'
- Embedding the web applications via an iframe is forbidden; Mitigates clickjacking attacks
object-src 'none'
- Resources embedded via object, embed or applet tags are not loaded
- Mitigates the exploitation of bugs that are included in third-party plugins (e. g. Adobe Flash, Java Applets, etc.)
sandbox allow-forms allow-scripts allow-same-origin allow-popups
- The site is rendered inside a sandbox
- Submitting forms, executing scripts, accessing the local storage as well as opening popups must be allowed since the web applications make use of these mechanisms

If you want to configure all of the directives introduced above, the policy would look as follows:

base-uri 'self';
default-src 'self' 'unsafe-inline' 'unsafe-eval';
img-src 'self' data:;
block-all-mixed-content;
form-action 'self';
frame-ancestors 'none';
object-src 'none';
sandbox
  allow-forms
  allow-scripts
  allow-same-origin
  allow-popups

Heads-up!

Please keep in mind that a configuration which is more strict than the one introduced above might break the functionality of the web applications.

Content-Type Options

If the Content-Type Options header is enabled, the browser uses the mime type declared in the Content-Type header to render a resource and prevents trying to guess the mime type by inspecting the actual content of the byte stream (sniffing).

Where to Configure?

Choose a container from the list and learn where to configure the HTTP Security Headers:

How to Configure?

The following table shows the possible configuration settings and the default behavior:

Name	Attribute	Configuration	Default
`X-XSS-Protection`	`xssProtectionDisabled`	The header can be entirely disabled if set to `true`. Allowed set of values is `true` and `false`.	`false`
	`xssProtectionOption`	The allowed set of values: `BLOCK`: If the browser detects a cross-site scripting attack, the page is blocked completely `SANITIZE`: If the browser detects a cross-site scripting attack, the page is sanitized from suspicious parts (value `0`) Note: Is ignored when `xssProtectionDisabled` is set to `true` Cannot be set in conjunction with `xssProtectionValue`	`BLOCK`
	`xssProtectionValue`	A custom value for the header can be specified. Note: Is ignored when `xssProtectionDisabled` is set to `true` Cannot be set in conjunction with `xssProtectionOption`	`1; mode=block`
`Content-Security-Policy`	`contentSecurityPolicyDisabled`	The header can be entirely disabled if set to `true`. Allowed set of values is `true` and `false`.	`false`
	`contentSecurityPolicyValue`	A custom value for the header can be specified. Note: Property is ignored when `contentSecurityPolicyDisabled` is set to `true`	`base-uri 'self'`
`X-Content-Type-Options`	`contentTypeOptionsDisabled`	The header can be entirely disabled if set to `true`. Allowed set of values is `true` and `false`.	`false`
	`contentTypeOptionsValue`	A custom value for the header can be specified. Note: Property is ignored when `contentSecurityPolicyDisabled` is set to `true`	`nosniff`

Options