Sec-Fetch-Site is an HTTP request header that provides modern defense against Cross-Site Request Forgery (CSRF) attacks by communicating the origin context of a request to the server. As part of the Fetch metadata request headers specification, this header enables servers to make informed decisions about request legitimacy without relying on traditional token-based mechanisms¹⁾.

The Sec-Fetch-Site header is automatically added by modern web browsers to HTTP requests and indicates the relationship between the requesting site and the target origin. Unlike traditional CSRF tokens that require developers to manage stateful session data, this header leverages the browser's inherent knowledge of request context to provide transparent protection²⁾.

The header can contain one of four possible values:

* same-origin: The request originates from the exact same origin (scheme, domain, and port all match) * same-site: The request comes from a site on the same registrable domain but potentially different subdomain * cross-site: The request originates from a completely different site * none: The request was user-initiated or the browser cannot determine the context

By evaluating these values, servers can reject suspicious cross-site requests while permitting legitimate same-origin operations, effectively blocking CSRF attacks at the HTTP layer³⁾.

The Sec-Fetch-Site header is part of a broader set of Fetch metadata request headers that includes Sec-Fetch-Mode, Sec-Fetch-Dest, and Sec-Fetch-User. These headers are automatically set by compliant browsers and cannot be forged by JavaScript code running in web pages, providing cryptographic-grade trust in their values⁴⁾.

Server-side implementation requires examining the header value in request handlers and applying authorization logic. For state-changing operations (POST, PUT, DELETE), servers should reject requests where Sec-Fetch-Site equals “cross-site”. For sensitive data endpoints (GET), servers may choose to also reject cross-site requests depending on risk assessment⁵⁾.

The protection works because browsers enforce same-origin policy restrictions on form submissions and JavaScript fetch calls. A malicious website cannot trigger a POST request to a target site and inspect the response if that site uses Sec-Fetch-Site validation, since the browser will not allow JavaScript access to the response body.

Traditional CSRF protection using tokens requires developers to: * Generate unique tokens per session or request * Store tokens in server-side session storage * Embed tokens in HTML forms * Validate token presence and value on each state-changing request

This approach introduces operational complexity, requires session management overhead, and can create scaling challenges in distributed systems. Sec-Fetch-Site header protection eliminates these requirements by delegating context verification to the browser, which already has this information⁶⁾.

The header-based approach is stateless, requiring no server-side session data, and automatic, providing protection without developer effort to embed tokens in templates or validate them in code.

Sec-Fetch-Site is supported in all modern browsers including Chrome, Firefox, Safari, and Edge. However, support is not universal across all clients, particularly older browser versions and non-browser HTTP clients that may not implement the header⁷⁾.

Servers implementing this protection should apply a defense-in-depth strategy, using Sec-Fetch-Site as the primary CSRF protection layer while maintaining backward compatibility with token-based mechanisms for older clients. Additionally, servers must implement proper SameSite cookie attributes on session cookies to prevent exploitation through cross-site cookie transmission, complementing the Sec-Fetch-Site validation.

Major web frameworks and platforms increasingly include built-in support for Sec-Fetch-Site validation. Tools like Datasette, various Python web frameworks, and Node.js middleware now offer configuration options to enable this protection automatically. Datasette is transitioning away from token-based CSRF protection in favor of Sec-Fetch-Site validation, a change that simplifies the codebase and eliminates the need to selectively disable protection for external APIs⁸⁾.

The approach represents a shift toward browser-based security primitives that reduce the attack surface for developers while improving defense mechanisms. Organizations implementing Sec-Fetch-Site protection should monitor their request logs to identify clients that do not send the header and evaluate whether exempting those clients creates unacceptable security risks. In scenarios where compatibility with legacy systems is unavoidable, hybrid approaches using both Sec-Fetch-Site validation and traditional tokens provide comprehensive coverage.

• API Endpoint Security
• Web Fetch Tool
• Access Control Vulnerabilities