SvelteKit FastAPI dual-cookie CSRF session: Logged-in users intermittently see 'couldn't load' error on page load
SvelteKit app with a FastAPI backend using a dual-cookie CSRF session scheme (a signed info cookie with SameSite=Lax plus an encrypted session cookie with SameSite=Strict, httponly). Logged-in users intermittently see the error state ('couldn't load') on a page whose +page.server.ts load fetches a user-scoped GET endpoint, while the rest of the app looks fine. Could not reproduce with a normal login in dev: navigation and refresh both worked. Checked the SSR cookie forwarding (AsyncLocalStorage per-request Cookie header injection) into the API client — correct. The load function swallowed the failure with .then(r => r.status === 200 ? r.data : null), so no error was ever logged and the 401 was invisible; only network-level rejections hit the catch/log path. Initially suspected the SvelteKit hook's auth gate, but it verified only the Lax info cookie, so the page shell rendered fine — only the API call inside the load failed.
Root cause: the user arrived via a cross-site link (email, GitHub, chat). SameSite=Strict cookies are withheld on cross-site top-level navigations, so the document request reaches the SSR server with only the Lax info cookie. The server-side load forwards exactly the cookies it received, the API resolves the session as 'partial' (info cookie only), and the GET endpoint 401s because its auth dependency demanded the full session state (both cookies) even for reads.
The fix that preserves the CSRF model: make read auth accept partial sessions for safe methods only.
_SAFE_METHODS = frozenset({"GET", "HEAD", "OPTIONS"})
def _session_identity(request: Request) -> str | None:
web_session = get_session_from_request(request)
if not web_session.is_authenticated:
return None
if web_session.state == "full" or request.method in _SAFE_METHODS:
return web_session.identity_id
return NoneThis is safe because the CSRF threat model only concerns state-changing requests: a cross-site attacker cannot read the response of a top-level navigation (it renders as the victim's page), and the Lax cookie is never sent on cross-site subresource fetches. Writes stay double-gated: a verb-based CSRF middleware 403s POST/PUT/PATCH/DELETE on non-full sessions before route auth, and the method check above is defense in depth.
Two diagnostic gotchas that hid this:
.then(r => r.status === 200 ? r.data : null)in the SvelteKit load silently converted the 401 into an empty/error state with zero logging. Log non-200 statuses explicitly, not just thrown fetch errors.- Reproduce with a partial session by deleting the Strict cookie in devtools (or navigating from another origin). A same-site login flow in dev never exhibits it, and in Chromium even a reload after a cross-site arrival re-sends Strict cookies, so 'refresh always fails' repros are browser-dependent (WebKit retains the original navigation's cross-site classification on reload).