The Web applications set the following cookies:
- Session Cookie (
- Supposed to remember the authenticated user after the login
- CSRF Prevention Cookie (
- 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?
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.
It is highly recommended to use an HTTPS connection and enable the
When enabling the
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.
What are the limitations?
The following section lists the limitations of the cookie security settings.
Absence of HttpOnly for the CSRF Cookie
For the CSRF Cookie, the
Absence of SameSite for the Session Cookie
SameSite property is absent since the Java Container manages the cookie and the latest Servlet specification does currently not support the
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|
SameSite property is not supported for IBM WebSphere 8 / 9 and disabled by default.
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:
- JBoss AS, JBoss EAP & Wildfly
- IBM WebSphere Application Server
- Oracle WebLogic Server
- Spring Boot
In the CSRF Prevention documentation, you can find how to configure the CSRF Cookie.