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,
Content-Type Options
as well as Strict Transport Security
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 executecam-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
- Embedding the web applications via an
object-src 'none'
- Resources embedded via
object
,embed
orapplet
tags are not loaded - Mitigates the exploitation of bugs that are included in third-party plugins (e. g. Adobe Flash, Java Applets, etc.)
- Resources embedded via
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).
Strict Transport Security
When enabled, the browser remembers that the Webapps must be accessed via HTTPS. After the initial HTTPS request, all subsequent requests will be redirected to HTTPS on the client-level — even though the user tries to access the Webapps via HTTP.
Heads-up!
- The Strict Transport Security header is disabled by default. When going into production, it is highly recommended to enable Strict Transport Security and Strengthen the Base Configuration to protect the Webapps against man-in-the-middle attacks.
- When accessing the Webapps via HTTP, the Strict Transport Security header is ignored. Therefore, make sure to redirect HTTP requests to HTTPS.
Base Configuration
After enabling the Strict Transport Security header, the base configuration is relatively lax:
max-age=31536000
Strengthen the Base Configuration
We encourage you to use a stricter configuration. Here you can find hints on how to strengthen the Base Configuration. Please also see the section on How to Configure?
Max Age
The higher the value, the better: after expiration, the Webapps can be accessed via HTTP, which is prone to be exploited by attackers.
Include Subdomains
If you can answer the questions below with yes, you should consider enabling the includeSubdomains
flag:
- Are the Webapps the only web services provided under your domain?
- Additionally to the main domain, are there any subdomains redirected to the Webapps
(e.g.,
www.example.com
is redirected toexample.com
)?
Preload
To even avoid the initial HTTP request (redirected to HTTPS), you can submit your domain to the
Preload List Service maintained by Google and set the
Strict Transport Security header according to the
Submission Requirements with the help of
the config property hstsValue
.
Where to Configure?
Choose a container from the list and learn where to configure the HTTP Security Headers:
- Tomcat
- JBoss AS, JBoss EAP & Wildfly
- IBM WebSphere Application Server
- Oracle WebLogic Server
- Spring Boot
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:
Note:
|
BLOCK |
|
xssProtectionValue |
A custom value for the header can be specified. Note:
|
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 |
|
Strict-Transport-Security |
hstsDisabled |
Set to false to enable the header. The header is disabled by default. Allowed set of values is true and false .
|
true |
hstsMaxAge |
Amount of seconds, the browser should remember to access the webapp via HTTPS. Note:
|
31536000 |
|
hstsIncludeSubdomainsDisabled |
HSTS is additionally to the domain of the webapp enabled for all its subdomains. Note:
|
true |
|
hstsValue |
A custom value for the header can be specified. Note:
|
max-age=31536000 |