Cookie Security
Camundas 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.
Absence of HttpOnly for the CSRF Cookie
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.
Absence of SameSite for the Session Cookie
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.
Session Cookie
Here you can find how to configure the session cookie for the following containers:
- Tomcat
- JBoss AS, JBoss EAP & Wildfly
- IBM WebSphere Application Server
- Oracle WebLogic Server
- Spring Boot
CSRF Cookie
In the CSRF Prevention documentation, you can find how to configure the CSRF Cookie.