> Sec-Fetch-Site: cross-site

TL;DR: Sec-Fetch-Site is a request header the browser adds to every HTTPS request, saying whether it came from your own origin, your own site, another site (cross-site), or a direct user action (none). Servers use it to drop cross-site requests that are not plain page navigations, which blocks most CSRF and cross-site data leaks with a few lines of middleware.

What the browser sends

POST /transfer HTTP/1.1
Host: bank.example
Origin: https://evil.example
Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: navigate
Sec-Fetch-Dest: document
Cookie: session=abc123
Content-Type: application/x-www-form-urlencoded

That is what a victim’s browser sends when a hidden form on evil.example auto-submits to your site. The cookie is attached (depending on SameSite), and the Origin header is there too, but Sec-Fetch-Site gives you a one-token answer instead of making you parse and compare origins.

It is a structured-field token, defined in section 2.3 of the W3C Fetch Metadata spec. It is a forbidden request header, so scripts cannot set it.

Values

Value	Meaning
same-origin	Same scheme, host, and port as the target URL.
same-site	Same scheme and registrable domain, but a different host or port, for example app.example.com calling api.example.com.
cross-site	Anything else, including http to https on the same domain.
none	Not initiated by a page: the user typed the URL, used a bookmark, dragged a link, or the browser opened it on its own.

Two details that trip people up:

• Redirects count. The browser evaluates the whole redirect chain. If a request started on evil.example, bounced through example.com, and landed on example.com, the final request is cross-site. If the chain only ever touched the same site it stays same-site, and same-origin requires every hop to match.
• Scheme matters. Fetch Metadata uses schemeful same-site, so http://example.com to https://example.com is cross-site.

Which browsers send it

From MDN’s compatibility data: Chrome and Edge 76, Firefox 90, Safari 16.4 (March 2023). MDN marks it widely available since March 2023. Anything older, and every non-browser client, sends nothing. That is why every sane policy starts with “if the header is absent, allow”.

It is also only sent to potentially trustworthy URLs: HTTPS, and localhost for development. Behind a TLS-terminating load balancer this is fine, because the browser decides based on the URL it requested, not what reaches your app.

Resource isolation policy

The pattern recommended by web.dev: reject cross-site requests unless they are plain navigations. Public endpoints that are supposed to be embedded or called cross-origin get an explicit exemption.

allow if Sec-Fetch-Site is absent                    # old browsers, curl, webhooks
allow if Sec-Fetch-Site is same-origin, same-site or none
allow if mode is navigate, method is GET, and dest is not object or embed
allow if the path is on your public cross-origin list
otherwise reject with 403

Express

const SAME = new Set(['same-origin', 'same-site', 'none'])
const PUBLIC_PATHS = new Set(['/favicon.png', '/api/public/status'])

function resourceIsolation(req, res, next) {
  const site = req.get('Sec-Fetch-Site')
  if (!site || SAME.has(site)) return next()

  const isSimpleNavigation =
    req.get('Sec-Fetch-Mode') === 'navigate' &&
    req.method === 'GET' &&
    !['object', 'embed'].includes(req.get('Sec-Fetch-Dest'))
  if (isSimpleNavigation || PUBLIC_PATHS.has(req.path)) return next()

  res.set('Cache-Control', 'no-store')
  res.status(403).type('text/plain').send('Cross-site request blocked')
}

app.use(resourceIsolation) // before sessions, auth, body parsing

Put it first. web.dev’s advice is to reject before authentication or any other processing so the response time does not leak information.

nginx

nginx has no if that can combine four variables cleanly, so build one key with map. Regex entries in a map are tried in the order written, and the first match wins.

# $http_sec_fetch_site is empty when the header is absent
map "$http_sec_fetch_site|$http_sec_fetch_mode|$http_sec_fetch_dest|$request_method" $fetch_blocked {
    default                                                      1;
    "~^\|"                                                       0;  # header absent
    "~^(same-origin|same-site|none)\|"                           0;
    "~^cross-site\|navigate\|(document|iframe|frame)\|GET$"      0;  # simple navigation
}

server {
    listen 443 ssl;

    location / {
        if ($fetch_blocked) { return 403; }
        proxy_pass http://app;
    }

    location = /api/public/status {
        proxy_pass http://app;   # intentionally cross-origin
    }
}

if inside location is fragile in general, but if (...) { return ...; } is the one use that is safe. Include Sec-Fetch-Site in Vary if a CDN in front of this caches the responses, otherwise a cached 200 can be served to a request that should have been rejected.

CSRF defence-in-depth

Rejecting cross-site on POST, PUT, PATCH, and DELETE is the part of the policy that matters for CSRF. OWASP’s CSRF cheat sheet describes it as a lightweight way to block obvious cross-site requests, with the caveat that browsers without the header need a fallback such as an Origin check or a token. Treat it as a layer in front of your CSRF tokens and SameSite cookies, not a replacement.

Things the policy breaks if you do not plan for them:

• Cross-site form POST callbacks. SAML POST binding and OpenID response_mode=form_post end with the identity provider posting a form to your callback. That request is cross-site, navigate, POST. Exempt that path.
• Webhooks from browsers’ point of view. Server-to-server webhooks carry no header and pass. A browser-based payment return that POSTs back to you does not.
• Public APIs called with CORS. A fetch() from another origin arrives as cross-site with mode cors. If the API is meant for that, exempt it, and keep CORS headers on it.
• Hotlinked assets. Images, fonts, and scripts you want third parties to embed arrive as cross-site and no-cors.

Debugging

Check what your own browser sends. In DevTools, open the Network panel, pick a request, and look under Request Headers. From the command line, send what a browser would:

curl -i https://example.com/api/transfer -X POST \
  -H 'Sec-Fetch-Site: cross-site' -H 'Sec-Fetch-Mode: cors' -H 'Sec-Fetch-Dest: empty'

curl lets you set Sec-* headers because the restriction exists only in browser scripts, which is exactly why the header proves nothing about non-browser clients.

For the resource side of the same idea, see Cross-Origin-Resource-Policy, which makes the response declare who may load it. Sec-Fetch-Site is the request-side version, and it is more flexible because the server can decide per request.

Related

• Sec-Fetch-Mode, Sec-Fetch-Dest, Sec-Fetch-User
• Origin and CORS guide
• 403 Forbidden