Sec-Fetch-Site

Cross-site request forgery and data exfiltration rely on browsers making requests across origin boundaries. The Sec-Fetch-Site request header reports the origin relationship between the request initiator and the target resource.

Baseline: Limited availability

Supported in Chromium-based browsers (Chrome, Edge, Opera), Firefox, and Safari. webstatus.dev

Usage

The Sec-Fetch-Site header is part of the Fetch Metadata Request Headers specification. Browsers set this header automatically on every request, providing the server with a trustworthy signal about the origin relationship.

Servers use Sec-Fetch-Site to enforce origin-based access policies. An API endpoint serving sensitive data accepts requests marked same-origin and rejects requests marked cross-site. A resource serving public assets like fonts or images applies less restrictive rules because cross-site embedding is expected.

The header works alongside Sec-Fetch-Dest, Sec-Fetch-Mode, and Sec-Fetch-User to give servers a complete request context. Together, these headers enable resource isolation policies protecting against cross-site request forgery, data exfiltration, and speculative execution attacks.

When a server decides to reject a request based on the site relationship, a 403 response is the standard rejection signal.

Directives

cross-site

The request originates from a site with a different registrable domain. Loading a font from cdn.other.re on a page hosted at app.example.re produces this value.

same-site

The request originates from the same registrable domain but a different origin. Two origins sharing the top-level domain qualify as same-site even when scheme or port differs. For example, https://api.example.re and https://www.example.re are same-site.

same-origin

The request originates from the exact same origin, matching scheme, host, and port. A fetch() call from https://example.re to https://example.re/api/data produces this value.

none

The request is user-initiated and does not originate from a page context. Typing a URL directly in the address bar, opening a bookmark, or dragging a link into the browser window produces this value.

Example

A user types a URL in the address bar and navigates directly. The browser marks the request as user-initiated with no originating site.

Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Sec-Fetch-Dest: document
Sec-Fetch-User: ?1

A page at https://app.example.re makes a fetch call to https://api.example.re/data. Both share the same registrable domain, so the browser labels the request as same-site.

Sec-Fetch-Site: same-site
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty

A page at https://example.re loads an image from https://images.otherdomain.net. The registrable domains differ, producing a cross-site value.

Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: no-cors
Sec-Fetch-Dest: image

Note

The Sec- prefix on Sec-Fetch-Site and other Fetch Metadata headers prevents JavaScript from setting or modifying these values through fetch() or XMLHttpRequest. Browsers enforce the prefix as a forbidden header name, making the values resistant to spoofing from page-level scripts. Requests sent from tools like curl or Postman bypass this protection, so server-side policies relying on Fetch Metadata work best as a defense layer for browser-based traffic.

See also

Last updated: April 4, 2026