Deprecating csrf.checkOrigin removes the only way to fully disable the origin check, which trustedOrigins can't replace for missing-Origin requests

[glw907]

SvelteKit 2.61 deprecates kit.csrf.checkOrigin in favour of csrf.trustedOrigins. For an app or library that owns CSRF itself, trustedOrigins is not an equivalent replacement, and the deprecation puts the use case on a removal path with no migration target.

The use case

We maintain a CMS library whose admin uses JS-free <form> POSTs (a passwordless magic-link sign-in that must work with no client JS). The library validates its own __Host--prefixed double-submit CSRF token inside a handle hook, so the consuming app sets csrf: { checkOrigin: false } to hand the library sole CSRF authority. This is necessary because some privacy-hardened browsers send no Origin header on a top-level form POST.

Why trustedOrigins can't replace checkOrigin: false

In runtime/server/respond.js the check forbids a request when:

request_origin !== url.origin &&
(!request_origin || !options.csrf_trusted_origins.includes(request_origin))

The !request_origin clause forbids a missing-Origin POST regardless of trustedOrigins, so no list value (including ['*']) lets it through. Only disabling the check entirely works.

Why a handle hook can't compensate

The check runs at the top of respond(), before the handle hook, so a library can't intercept it or opt out from where it does its own validation.

Request

Keep a supported way to fully disable SvelteKit's origin check (or to allow a missing-Origin request) for apps that own CSRF themselves, before checkOrigin is removed. Options: retain a global disable, let trustedOrigins opt into accepting an absent Origin, or run the check after handle so a hook can own it.

[Rich-Harris]

Just researched this a bit, and it seems best practices have changed since we first designed this: instead of checking that request_origin === url.origin, we can check that the sec-fetch-site header is same-origin. (Maybe we should fall back to checking origin for legacy purposes? Though sec-fetch-site seems very well supported.)

some privacy-hardened browsers send no Origin header on a top-level form POST

This was... surprising to me, insofar as it encourages servers to weaken CSRF checks. But apparently there are indeed some edge cases around Tor, and Firefox in extra-paranoid mode.

For us to switch to sec-fetch-site it would be helpful to know for certain that the header is sent in the cases you've encountered — would you be able to check that and report back?

[Nic-Polumeyv]

trustedOrigins: ['*'] does disable the check entirely, not just for listed origins: write_server.js sets csrf_check_origin to false when the array contains '*', and respond.js skips is_csrf_forbidden altogether in that case, so a request with no Origin header goes through. That's been the case since the deprecation commit (#14281), so the escape hatch you're describing already exists.