Сross-Site Request Forgery (CSRF) protection in TeamCity implies a number of requirements on HTTP requests.
Since version 2020.1, TeamCity uses only CSRF tokens as a protection measure. In previous versions of TeamCity,
Origin/Referer headers were also used.
To obtain a security token, send the
GET https://your-server/authenticationTest.html?csrf request.
To pass the token, use the
X-TC-CSRF-Token HTTP request header or the
tc-csrf-token HTTP parameter.
CSRF checks for HTTP request
When considering HTTP request safety from the TeamCity perspective, the following checks are sequentially made:
If an HTTP request is a non-modifying one (such as
GET), it is considered safe.
If an HTTP request has a secure CSRF token either in the parameter or in the HTTP header and this token matches the one stored in user session, it is considered safe.
Implications for non-browser HTTP clients
For non-browser API access, we recommend using token-based authentication of the request and disabling cookie support in your HTTP client.
Implications for CORS clients
To use CORS request, configure the CORS support as described here. This configuration will be enough for
If you need to send
POST/PUT/DELETE requests via CORS, you should obtain a CSRF token using the
authenticationTest.html?csrf call, and then provide this token with your modifying HTTP requests.
If you face problems regarding CSRF protection in TeamCity (for example, you get the "Responding with 403 status code due to failed CSRF check" response from the server), you can try these steps:
Enforce verification of
Origin/Refererheaders for CORS operations by setting the
teamcity.csrf.paranoid=falseinternal property, similarly to how it worked in TeamCity versions prior to 2020.1 (read our Upgrade Notes) for more details).
Temporary disable CSRF protection at all by setting the
Information about failed CSRF attempts is logged into
TeamCity/logs/teamcity-auth.logfiles. For more detailed diagnostics of the requests, enable the debug-auth logging preset.