XSRF Security Token Missing error occurs in Bitbucket Server
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
Problem
While creating a repository or a project in Bitbucket Server, the action fails with the following or a similar message:
XSRF Security Token Missing
Bitbucket Server could not complete this action due to a missing or expired form token.
You may have cleared your browser cookies, which could have resulted in the expiry of your current form token.
A new form token has been issued.
The original input has been captured and you can retry the operation.
Any file attachments in the original input will be lost
Other actions may fail with this or a similar message as well.
Causes
There are several possible root causes of this problem. Use the list below to identify which one is applicable to your situation and then refer to the relevant solution from the Resolution section below.
Cause 1
You are using a reverse proxy server or load balancer in front of Bitbucket Server or Data Center, and haven't added the required configuration parameters to bitbucket.properties
Cause 2
You are using a reverse proxy server in front of Bitbucket Server or Data Center that is using HTTP Basic Authentication (mod_auth_basic).
Bitbucket Server explicitly invalidates the HTTP session at the end of every request which uses basic authentication for scalability to avoid Tomcat holding a possibly large amount of sessions that were created having serving only one request. As a result, anything which relies on sessions to work (e.g. XSRF protection) will no longer work.
Cause 3
The Tomcat connector is insecure but the configuration contains the secure
attribute.
Cause 4
You are running multiple Atlassian products at the same base URL, with the only difference being the port number of each application. For instance Bitbucket Server is reachable via http://server.domain.com:7990 and Jira is reachable via http://server.domain.com:8080
Java web applications identify your session by setting a cookie in your browser. This cookie is bound to the hostname and path that each application is deployed to, but ignores the port. Applications that reside at URLs where only the port is different may unintentionally overwrite each other's session information, resulting in lost sessions.
Cause 5
You are running Bitbucket Data Center behind a load balancer that is not configured to use sticky sessions.
Cause 6
You have configured Bitbucket Server to use SSL, but are not redirecting HTTP requests to HTTPS.
Cause 7
You upgraded from Bitbucket Server version 4 or earlier to Bitbucket Server version 5 or newer and have carried over the jvmRoute
property from server.xml
in the previous version.
Resolution
Please refer to the possible causes above and identify the relevant solution below:
Solution for Cause 1
To resolve the problem, several parameters need to be added to the <BitbucketHome>/shared/bitbucket.properties
, depending on the base URL that you have configured for Bitbucket Server.
If your base URL is a "standard" port-less URL using the insecure HTTP protocol (such as http://bitbucket.domain.com/), add the following properties, where
<fqdn>
is the fully-qualified domain name from the base URL (bitbucket.domain.com
in this example):server.secure=false server.scheme=http server.proxy-port=80 server.proxy-name=<fqdn>
If your base URL is a URL that includes a port and is using the insecure HTTP protocol (such as http://bitbucket.domain.com:8080/), add the following properties, where
<fqdn>
is the fully-qualified domain name from the base URL (bitbucket.domain.com
in this example) and<port>
is the port:server.secure=false server.scheme=http server.proxy-port=<port> server.proxy-name=<fqdn>
If your base URL is a "standard" port-less URL using the secure HTTPS protocol (such as https://bitbucket.domain.com/), add the following properties, where
<fqdn>
is the fully-qualified domain name from the base URL (bitbucket.domain.com
in this example):server.secure=true server.scheme=https server.proxy-port=443 server.proxy-name=<fqdn>
If your base URL is a URL that includes a port and is using the secure HTTPS protocol (such as https://bitbucket.domain.com:444/), add the following properties, where
<fqdn>
is the fully-qualified domain name from the base URL (bitbucket.domain.com
in this example) and<port>
is the port:server.secure=true server.scheme=https server.proxy-port=<port> server.proxy-name=<fqdn>
Once you are done, restart Bitbucket Server. If you are using Bitbucket Data Center, restart all nodes.
Solution for Cause 2
Disable the HTTP Basic Authentication within the proxy settings.
Related issue: - BSERV-4667Getting issue details... STATUS
Solution for Cause 3
- Stop Bitbucket Server.
- Bitbucket Server 5.0+
- Remove the
server.secure=true
attribute from$BITBUCKET_HOME/shared/bitbucket.properties
- Remove the
- Bitbucket Server 4.x and below
- Remove the secure="true" attribute and value from:
$BITBUCKET_HOME/shared/server.xml
- Remove the secure="true" attribute and value from:
- Start Bitbucket Server.
Solution for Cause 4
Add a context path for Bitbucket Server. Please see Change Bitbucket's context path.
Solution for Cause 5
Enable sticky sessions (also known as session affinity) on the load balancer.
Solution for Cause 6
Follow the instructions at Redirect HTTP Requests to HTTPS to redirect requests from HTTP to HTTPS.
Solution for Cause 7
Add the following to the JVM_SUPPORT_RECOMMENDED_ARGS
environment variable in the <BitbucketInstallation>/bin/_start-webapp.sh
file for each node
JVM_SUPPORT_RECOMMENDED_ARGS="-DjvmRoute=<NAME OF NODE AS SET BY -Dcluster.node.name PROPERTY>