Browsers attach Sec-Fetch headers to requests, telling your server whether each request came from the same origin, the same site, another site, or the user directly. A resource isolation policy checks them and returns 403 for cross-site requests that should not be allowed, which blunts CSRF and cross-site leak attacks.
The four headers
MDN's fetch metadata guide lists four headers: Sec-Fetch-Site, Sec-Fetch-Mode, Sec-Fetch-User and Sec-Fetch-Dest. Because they begin with Sec-, they are forbidden request headers, so front end code cannot set or change them. They are only sent to potentially trustworthy URLs, which means HTTPS servers receive them and plain HTTP servers do not.
| Header | What it tells you | Example values |
|---|---|---|
| Sec-Fetch-Site | Relationship between requester and your origin | same-origin, same-site, cross-site, none |
| Sec-Fetch-Mode | How the request was made | navigate, cors, no-cors, same-origin |
| Sec-Fetch-Dest | How the response will be used | document, script, image, empty |
| Sec-Fetch-User | Present only for user initiated navigation | ?1 |
The value none means a direct user action such as typing a URL or using a bookmark.
A resource isolation policy
MDN describes a common policy: allow same-origin requests, allow directly user initiated requests, allow top-level navigations from other sites so links to you work, and allow specific endpoints that are meant to be cross-origin, such as ones using CORS. Deny the rest.
function isAllowed(req) {
const site = req.headers["sec-fetch-site"];
if (site === "same-origin" || site === "none") return true;
const mode = req.headers["sec-fetch-mode"];
if (mode === "navigate" && req.method === "GET") return true;
return false;
}
If the request fails the check, respond with 403. MDN's example also sets a Vary header listing the fetch metadata headers it used, so a cache will only serve a stored response to requests with matching values.
What it protects against
MDN distinguishes two cross-origin attack types. In cross-site request forgery, a request from another site makes a consequential change using the victim's cookies. In cross-site leaks, the attacker uses a request to learn about the victim's relationship with your site through side channels. A policy that rejects unexpected cross-site requests handles both for the endpoints it covers.
MDN also points out that a subdomain takeover is cross-origin but same-site, so if you trust sibling subdomains less than your main origin, check for same-origin only.
Rollout steps
- Log the three headers for a week without blocking, grouped by route.
- Mark routes that must accept cross-site traffic: public pages, webhooks, OAuth callbacks, embeddable widgets.
- Apply the policy to state changing and private routes first.
- Add the Vary header on responses that depend on it.
- Keep your CSRF tokens or SameSite cookies. Fetch metadata is an extra layer.
Older browsers that do not send the headers will have no value to check, so decide in advance whether a missing header means allow or deny, and test it.
Try it yourself
Open the API security scan, find an endpoint that changes state, and think about which Sec-Fetch values it should accept.
Click through it at your own pace, or open it full screen.
Quick check
Can an attacker forge Sec-Fetch-Site?
Not from a web page. MDN says Sec- prefixed headers cannot be set by front end code. A non-browser client can send anything, so this protects browser users, not API authentication.
Does it replace SameSite cookies?
No. It adds a server side check beside them. See is SameSite enough to stop CSRF.
Safeguard scans dependencies and builds SBOMs, which covers the libraries behind your request handling. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
