Sec-Fetch-Site, Sec-Fetch-Mode, Sec-Fetch-Dest and Sec-Fetch-User explained (tested in Chromium)

Browsers add four Sec-Fetch-* headers (Fetch Metadata) to requests so the server can tell where a request came from and what it is for. We logged them for 18 kinds of request in Chromium 153, then blocked cross-site requests with a small policy and checked which ones got through.

1. The four headers

• Sec-Fetch-Site: how the requesting page relates to the target. same-origin, same-site (same registrable domain and scheme, other origin, e.g. another port or subdomain), cross-site, or none when the user started it (typed URL, bookmark).
• Sec-Fetch-Mode: the request mode: navigate for page loads, cors for normal fetch()/XHR, no-cors for images, scripts and fetch(…, {mode:'no-cors'}).
• Sec-Fetch-Dest: where the response will be used: document, iframe, image, script, empty (fetch/XHR) and others.
• Sec-Fetch-User: ?1 on navigations the user triggered (click, typed URL). It is left out otherwise; we never saw ?0.

2. What Chromium 153 sent, measured

The page making the request was http://localhost:8973. "Same-site" targets were localhost:8974, "cross-site" targets 127.0.0.1:8974.

Things worth noticing: a different port is still same-site, so Sec-Fetch-Site alone can't separate two apps on one host name. The CORS preflight (OPTIONS) carries the headers too, so a server can reject it before the real POST is ever sent. And a script can navigate cross-site; only the missing Sec-Fetch-User tells you no one clicked.

3. Only sent to trustworthy origins

Chromium only adds the headers when the target URL is potentially trustworthy: HTTPS, or localhost/127.0.0.1. With a host name mapped to 127.0.0.1 over plain http://, a typed URL, a fetch() and an <img> to it carried no Sec-Fetch-* headers at all. A fetch() from that http page to localhost did carry them (cross-site, cors, empty). So test on HTTPS or localhost, and expect the headers to be missing for plain-http sites, old browsers, curl and server-to-server calls.

4. A resource isolation policy (tested)

The common use is to refuse cross-site requests to an API or app, except ordinary link navigations. In Node.js:

function allowed(req) {
  const site = req.headers['sec-fetch-site'];
  if (!site) return true;                       // no Fetch Metadata: old browser, curl, http
  if (['same-origin', 'same-site', 'none'].includes(site)) return true;
  if (req.headers['sec-fetch-mode'] === 'navigate' && req.method === 'GET' &&
      !['object', 'embed'].includes(req.headers['sec-fetch-dest'])) return true;
  return false;                                 // cross-site fetch, img, script, form POST
}
// in the handler: if (!allowed(req)) { res.writeHead(403); return res.end(); }

With it in place, the same 18 requests gave:

Two caveats. Cross-site iframes are allowed by this policy (they are GET navigations); stop framing with X-Frame-Options or frame-ancestors. And because missing headers are allowed, it is defence in depth, not a replacement for CSRF tokens or SameSite cookies. Don't apply it to resources other sites are meant to load (public images, a CDN, an embeddable widget); for those, decide per path. Related: the Origin header and Cross-Origin-Resource-Policy, which lets the browser enforce a similar rule for no-cors loads. If you vary responses on these headers and something caches them, add them to Vary.

5. See them yourself

DevTools → Network → pick a request → Headers → Request Headers. Navigate by typing the URL and then by clicking a link to the same page, and Sec-Fetch-Site changes from none to same-origin.

Written with AI assistance. Measured on 2026-10-01 in headless Chromium 153.0.8010.12 (Playwright) against two Node.js HTTP servers that logged every Sec-Fetch-* header: localhost:8973 and localhost:8974 (same site, different origin) and 127.0.0.1:8974 (cross-site). A third host name mapped to 127.0.0.1 over plain http tested a non-trustworthy origin. The isolation policy below ran on the same servers and every allow/block result in the table was observed. Other browsers were not tested. PlainHeaders is our extension; DevTools → Network → Headers shows the same request headers, free.