XSRF Security Token Missing or session expiring in Jira

Still need help?

The Atlassian Community is here for you.

Ask the community

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:

  1. Generate a HAR file.
  2. Open the HAR file in HAR viewer and look for the first request "Headers" output of XNODE-ID and JSESSIONID. For example: 
    1. First Request
    2. Header output
  3. Look at the last request "Headers" output of XNODE-ID and JSESSIONID. For example: 
    1. Last Request
    2. Header output
  4. Please confirm both first and last requests of XNODE-ID and JSESSIONID are the same. 
    1. IF XNODE-ID is not the same, you are affected by Cause 1.
    2. 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-69791 - Getting 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-20347 - Getting issue details... STATUS

Jira 8.5.6:

JRASERVER-70574 - Getting issue details... STATUS

Jira 8.12.0:

JRASERVER-69054 - Getting 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:



Last modified on Mar 13, 2024

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.