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 CIB seven web applications by custom scripts and forms. Our default Content Security Policy defines some exceptions to ensure our web apps, your embedded forms, and embedded form scripts work out of the box.

Default Policy

The header value of the default policy looks as follows:

base-uri 'self';
script-src $NONCE 'strict-dynamic' 'unsafe-eval' https: 'self' 'unsafe-inline';
style-src 'unsafe-inline' 'self';
default-src 'self';
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 allow-downloads;

Where $NONCE is a placeholder that is replaced by a random generated secure string. This nonce can be then used to enable inline scripts in the index.html pages using another placeholder called $CSP_NONCE:

<script type="application/javascript" nonce="$CSP_NONCE">

Policy Details

We encourage you to use a strict Content Security Policy. This section describes what our default policy contains:

• base-uri 'self'
  • The URI of the HTML Base Tag must not point to a cross-origin
• script-src $NONCE 'strict-dynamic' 'unsafe-eval' https: 'self' 'unsafe-inline';
  • The browser only executes inline scripts that are explicitly whitelisted by adding a backend generated nonce to each script tag included in the index.html asset.
  • JavaScript’s eval(…) calls must be allowed to execute cam-script in Tasklist.
    • If there are no embedded forms in your application, it’s recommended to remove the 'unsafe-eval' directive.
  • The second part (https: 'self' 'unsafe-inline') is a fallback for browsers that don’t support strict-dynamic yet (non CSP3 compliant browser).
    • Script resources must not point to a cross-origin.
    • Inline scripts must be allowed since the web applications make use of it.
• style-src 'unsafe-inline' 'self'
  • Style resources must not point to a cross-origin.
  • Inline styles must be allowed since the web applications make use of it.
• default-src 'self'
  • Any other unspecified resources must not point to a cross-origin.
• 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 allow-downloads
  • The site is rendered inside a sandbox.
  • Submitting forms, executing scripts, accessing the local storage, opening popups as well as downloading files must be allowed since the web applications make use of these mechanisms.

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.

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 to example.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 EAP & Wildfly
• Spring Boot

How to Configure?

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