Cookie Security

CIB seven Web applications use cookies to preserve user sessions and to prevent CSRF attacks. This page explains how these cookies should be configured to increase the security.

The Web applications set the following cookies:

  • Session Cookie (JSESSIONID)
    • Supposed to remember the authenticated user after the login
  • CSRF Prevention Cookie (XSRF-TOKEN)
    • Supposed to prevent Cross-Site Request Forgery (CSRF) by sending a newly generated token along with each modifying request

What are the properties supposed to be?

This section describes the purpose of security-related cookie properties. You can find more information about Secure and HttpOnly as well as SameSite cookies in Mozilla’s Developer Guide.

Secure

When enabling the Secure flag, the browser does not send the cookie via a plain (insecure) HTTP connection.

To provide a seamless getting started experience, we disabled the Secure flag by default for all cookies. However, you can easily enable the Secure flag. When the Secure flag is present, some browsers prevent cookies from being sent via a plain (insecure) HTTP connection.

Heads-up!

It is highly recommended to use an HTTPS connection and enable the Secure flag.

HttpOnly

When enabling the HttpOnly flag, the cookie cannot be read via JavaScript to mitigate cross-site scripting (XSS) attacks.

SameSite

When enabling the SameSite flag, the browser only sends the cookie if the client performs the request from the same domain that initially set the cookie. In case of a cross-site request, the browser will not send the cookie.

Heads-up!

The standard related to SameSite recently changed. Most current browser versions treat cookies without SameSite attributes as ‘SameSite=Lax’. Have a look at SameSite cookies in Mozilla’s Developer Guide.

What are the limitations?

The following section lists the limitations of the cookie security settings.

For the CSRF Cookie, the HttpOnly flag is absent and not configurable to ensure the functionality of the Web applications. Aforementioned is due to the reason that the CSRF cookie must be readable by the JavaScript HTTP Client to guarantee that the browser sends the token along with every modifying request.

In the following pre-packaged distributions, the SameSite property is absent by default since the Java Container manages the cookie and the latest Servlet specification does currently not support the SameSite property:

  • JBoss EAP/WildFly
  • IBM WebSphere
  • Oracle Weblogic

For all other distributions, the SameSite flag is enabled by default.

Heads-up!

The absence of the SameSite property does not have any negative impact on the security of the Web applications: The SameSite property is supposed to ensure protection from CSRF attacks. With the CSRF Protection Filter, there already exists a dedicated protection mechanism for such scenarios.

What are the defaults?

The following table shows the default configuration of the Web applications.

Property Name Session Cookie CSRF Cookie
HttpOnly true –
Secure false false
SameSite Lax * Lax *

* The SameSite property is not supported for IBM WebSphere and disabled by default for both cookies. The Session Cookie also has no SameSite attribute by default on JBoss EAP/WildFly and Oracle Weblogic.

SameSite & Firefox

Firefox prevents sending the Cookie to the server for all subsequent requests until the next restart …

  • … on Strict when opening the Webapps from a cross-origin (GET)
  • … on Lax when a modifying request (e. g. POST) is performed from a cross-origin

How to configure?

This section describes how to configure the Session Cookie as well as the CSRF Cookie.

Here you can find how to configure the session cookie for the following containers:

In the CSRF Prevention documentation, you can find how to configure the CSRF Cookie.

On this Page: