CSRF and the call headers
Before any server function code runs, the handler's CSRF check looks at every unsafe request.
Before any server function code runs, the handler's CSRF check looks at every unsafe request. Sec-Fetch-Site: same-origin passes. A request with another Sec-Fetch-Site passes only when its Origin is a trusted origin;
without that header the Origin, and then the Referer, must match this origin; a request that carries none of the
three is refused. The answer is 403 (CSRF check failed: <reason> in development, Forbidden in production) in
the server function wire format, so the stub rebuilds it as an HttpError. GET calls are safe methods and skip
the check.
The full order for one call is: URL length and framing guards, host, CSRF, handler-wide middleware, then the
endpoint's own checks (id, method, x-dusk-fn and content type, body size, decoding, schema), then the
function's middleware, then the handler.