Jan Sandbrink 0383ae171c Consider Sec-Fetch-Site header for session auth ...

This warden strategy is primarily used to allow APIv3 requests
from the browser, which only authenticates using its session cookie.

Since this is susceptible to cross-site-request-forgery, prevention of
CSRF must take place. This was so far only ensured through the usage of
the X-Requested-With header. When a client sent along this header, the
server could know that a CORS-preflight request must have been made and
thus the browser most certainly has validated that the request is valid
according to CORS rules.

However, the header itself is a non-standard header and while some JavaScript
frameworks add it to requests, not all of them do. For us this was practically
visible on the API docs hosted under `/api/docs`.

The solution is to expect the browser to send the Sec-Fetch-Site header with a value
of same-origin. This header can't be set through JavaScript, but only by the browser
and the value "same-origin" ensures that scheme, host and port are the same for requester
and requested endpoint, thus eliminating CSRF concerns. This feature is widely supported by
all major browsers, the last of which was Safari which added support 3 years ago.

We might want to consider dropping the check for X-Requested-With entirely, since it should be
superfluous. For now it was left in place for greater compatibility.

2026-05-12 08:13:14 +02:00

..

open_project

Consider Sec-Fetch-Site header for session auth

2026-05-12 08:13:14 +02:00

plugins

[#74746] Avoid additional journal background jobs to be started by Jira import job

2026-05-07 14:59:44 +02:00

redmine

Move format_date_range to Redmine::I18n

2026-04-20 17:29:58 +01:00

rubocop/cop/open_project

remove years from copyrights (except for COPYRIGHT file)

2024-07-31 15:02:49 +02:00