XSRF Security Token Missing or session expiring in Jira
Platform notice: Server and Data Center only. This article only applies to Atlassian products on the Server and Data Center platforms.
Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
Several times a day, Jira presents a XSRF Security Token Missing message when performing normal operations.
Other symptoms that share the same root cause and resolutions is "auto logout" or sessions expiring unexpectedly.
Environment
Jira Core 8.4.0 or later.
Previous versions may also benefit from the diagnosis and resolutions listed here, but Jira 8.4 shipped more strict session validations that may cause this behavior more often.
Diagnosis
The error is not easily reproducible and seems to occur at random, affecting several users on several different projects and operations.
This XSRF error occurs by several reasons. Each is mapped as the same number on Cause and it's correspondent Resolution.
The occurrence of this error might've started or increased after upgrading from a previous version of Jira to any more recent than 8.4.0. In some cases below exception is noticed in the Jira log
Caused by: java.io.IOException: Invalid Form Data, no boundary encountered.
To diagnose the issue:
- Generate a HAR file.
- Open the HAR file in HAR viewer and look for the first request "Headers" output of XNODE-ID and JSESSIONID. For example:
- First Request
- Header output
- First Request
- Look at the last request "Headers" output of XNODE-ID and JSESSIONID. For example:
- Last Request
- Header output
- Last Request
- Please confirm both first and last requests of XNODE-ID and JSESSIONID are the same.
- IF XNODE-ID is not the same, you are affected by Cause 1.
- IF JSESSIONID is not the same, you are affected by Cause 7.
Enable DEBUG on the package com.atlassian.jira.security.xsrf & http dump as well.
Cause
Jira 8.4 packed a security fix to improve the Cross-Site Request Forgery (CSRF) protection:
- JRASERVER-69791Getting issue details... STATUS
This improvement adds an additional security check that compares the XSRF token from the client with the value previously stored in Jira's server-side session. This means the XSRF check is more restrictive now, and some network setups (proxies, firewalls, load balancers) that used to work before Jira 8.4 might result in such XSRF errors now.
1) Jira DataCenter node switching
Jira DC requires "session stickiness" to function properly. If the load balancer is not correctly configured, more than one node will answer browser requests during the same sessions and this is not expected.
2) Other Atlassian applications on different contexts
You may have Jira and confluence under the same domain and only routed through a different context, like:
yourcompany.com/Jira
yourcompany.com/confluence
If Jira's session timeout is short, this may incur on XSRF errors when requests are performed after the session's been invalidated.
3) Short session timeout
If Jira's session timeout is short, this may incur on XSRF errors when requests are performed after the session's been invalidated.
4) Sessions prematurely terminated
Jira has a mechanism to identify inactive bot sessions and terminate them to free resources asap, yet this may cause false-positive session terminations and XSRF errors.
This is aggravated if using third party authentication, but not restricted to it.
5) Unfixed issues
Since Jira 8.4 several XSRF improvements have been published and may fix this XSRF behavior for you particular scenario.
6) JRASERVER-69054 and filter-mapping
One of the fixes was shipped in Jira 8.12 and has a workaround that can be implemented in previous versions, from 8.4.x to 8.11.x.
7) JSESSIONID cookie being modified by reverse-proxy or load balancer
Generating a HAR file during a couple of usual operations will provide the JSESSIONID cookie, there are settings on reverse-proxy or load balancer that might modify the cookie. There are several ways this can be disruptive to Jira functionality. Bypassing the proxy and accessing the instance directly is also a good way of determining if the load balancer or proxy is the cause.
8) Cookies are being removed by a browser extension
Some users or organizations will install browser extensions which remove cookies periodically. This can be disruptive to Jira's functionality and can be tested quite easily by disabling extensions or by using Jira in Incognito Mode.
9) Missing /work folder in the root of <jira-installation> directory, or the folder exists but the user running Jira does not have sufficient read and write permission to it
If you are observing the XSRF security token missing error only when uploading a new logo, or when creating Jira issues (with attachments) in a new tab, then the KB article XSRF Security Token Missing ERROR while uploading Jira Logo applies.
10) Action performed by a 3rd party plugin
Some issue actions provided by 3rd party plugin can cause XSRF errors. For example, uploading XML execution results with Xray plugin can cause XSRF error due to some required fields missing not having their values set.
11) Form Data was removed by the Proxy (F5)
Solution
1) Jira DataCenter node switching
Please ensure Jira load balancer has session stickiness (or node affinity) enabled and the cookie is configured to use JSESSIONID.
Please see the load balancer example that shows the type of Jira DC sticky sessions that are supported:
If you are using an F5 load balancer for Jira, please configure F5 to use sticky sessions with JSESSIONID cookies. In F5 configuration, you can review the cookies configuration as described below:
2) Other Atlassian applications on different contexts
Make sure your proxy and load balancer work with the JSESSIONID cookie.
Other load-balancing cookies (like AWS's native) may not work with context paths and you'll get XSRF errors whenever the browser makes requests between Jira and other Atlassian products like Confluence or Bit Bucket and Bamboo.
3) Short session timeout
Increase the session timeout on both web.xml as described on this changing the session timeout KB article.
4) Sessions prematurely terminated
Disable the Atlassian Bot Session Killer app as described in this KB on early session termination.
5) Unfixed issues
Upgrade Jira to benefit from the following fixes, just to name a few.
Jira 8.5.5:
- JSWSERVER-20347Getting issue details... STATUS
Jira 8.5.6:
- JRASERVER-70574Getting issue details... STATUS
Jira 8.12.0:
- JRASERVER-69054Getting issue details... STATUS
6) JRASERVER-69054 and filter-mapping
Until the upgrade to Jira 8.12 or later, the following workaround can be implemented if none of the previous helped fix the XSRF issue:
The solution to the above bug is to map the 'xsrf-token-addition' filter directly above the 'filter-plugin-dispatcher-before-decoration-request' filter in the $JIRA_INSTALL_DIR/atlassian-jira/WEB-INF/web.xml. All you need to do is add the following lines to the web.xml:
<!-- XSRF filter needs to be before any other filter that can send the first byte to the client, e.g. a dispatcher filter to avoid issues with Flush Head Early and BigPipe XSRF filter cannot add any headers/cookies to the already flushed responses More info: YET-70 --> <filter-mapping> <filter-name>xsrf-token-addition</filter-name> <url-pattern>/*</url-pattern> <dispatcher>REQUEST</dispatcher> </filter-mapping>
Paste them immediately above this section (roughly line 660 in the default web.xml):
<filter-mapping> <filter-name>filter-plugin-dispatcher-before-decoration-request</filter-name> <url-pattern>/*</url-pattern> <dispatcher>REQUEST</dispatcher> </filter-mapping>
7) JSESSIONID cookie being modified by reverse-proxy or load balancer
Verify the load balancer and/or reverse-proxy settings and documentation to assure no disruptive modifications are done to JSESSION cookies. For example: ProxyPassReverseCookiePath or ProxyPassReverseCookieDomain in httpd.
8) Cookies are being removed by a browser extension
Confirm that you do not have a browser extension installed which removes cookies by disabling all extensions or navigating Jira using Incognito Mode. If you do have a browser extension installed which has this behavior, you may need to add an exception for Jira's cookies or disable the extension.
9) Missing /work folder in the root of <jira-installation> directory, or the folder exists but the user running Jira does not have sufficient read and write permission to it
Check the diagnosis and resolution steps from the KB article XSRF Security Token Missing ERROR while uploading Jira Logo
10) Action performed by a 3rd party plugin
Please raise a vendor support request so they could analyze the problem with the action cause by their 3rd party plugin.
11) Check with the Proxy/LB team
for F5 LB The protocol profile (Client): tcp and HTTP profile (Client): http could be reviewed.
Workarounds
Jira 8.5.3 or later
If none of the previous solutions worked out, you may enable this feature flag (aka dark-feature) to revert back to the pre 8.4 XSRF checking method:
com.atlassian.jira.security.xsrf.session.token.disabled
Jira 8.5.2 or earlier
You may temporarily disable XSRF checks by including the following to the jira-config.properties, following the instructions on Edit the jira-config.properties file in Jira server.
jira.xsrf.enabled=false
We advise resorting to this workaround only temporarily, while you work on upgrading Jira to a version that this issue's been fixed for your scenario or that you're able to apply the feature flag workaround instead.
Related KB articles
Here's a collection of other KB articles related to this XSRF Security Token missing error. Please browse them if the advices on this article didn't prove useful: