Cybersecurity glossary
What is Sec-Fetch-Site?
Learn what the Sec-Fetch-Site request header means, how values like same-origin, same-site, and cross-site describe initiator context, and how it differs from Sec-Fetch-Mode, Sec-Fetch-User, and Sec-Fetch-Dest.
Definition
Sec-Fetch-Site is a Fetch Metadata request header that tells the server the relationship between the origin of the resource that initiated the request and the origin of the target URL—same-origin, same-site, cross-site, or none.
Why Sec-Fetch-Site matters
Many high-impact web attacks begin with a request the victim’s browser sends from an attacker-controlled page. Sec-Fetch-Site exposes whether that request is same-origin, same-site, cross-site, or has no initiator context—giving servers a cheap way to reject traffic that should never mutate account state.
This header answers a different question than Sec-Fetch-Mode (how the fetch was issued) or Sec-Fetch-User (whether a human click started a navigation). It focuses purely on the relationship between the initiator’s site and the target URL.
How Sec-Fetch-Site works
When a browsing context issues a request, the browser computes the site relationship and sends Sec-Fetch-Site on the wire. Server middleware can enforce allowlists before application code runs.
Initiator loads or embeds a URL
A page, iframe, worker, or direct user entry triggers an HTTP request.
Browser classifies site relationship
Algorithms compare initiator origin and target origin into same-origin, same-site, cross-site, or none.
Sec-Fetch-Site is sent
The value rides along with other Fetch Metadata headers on the request.
Server applies site policy
Routes that must only accept first-party traffic can reject cross-site early.
Layer with tokens and cookies
Combine site checks with CSRF defenses and SameSite=Lax or Strict where appropriate.
Sec-Fetch-Site values
same-origin
Initiator and target share scheme, host, and port—the strictest relationship.
same-site
Different origins but same registrable site, such as www and api subdomains on one eTLD+1.
cross-site
Initiator and target are not same-site; typical CSRF and cross-origin embed context.
none
No initiator browsing context, such as address-bar entry or some privacy-preserving loads.
Site vs mode vs user vs dest
| Header | Question it answers | Common confusion |
|---|---|---|
| Sec-Fetch-Site | How related are initiator and target origins? | Blocking cors mode when you meant cross-site |
| Sec-Fetch-Mode | What fetch algorithm ran? | Treating navigate as same-origin guarantee |
| Sec-Fetch-User | Was navigation user-activated? | Expecting it on XHR or fetch() calls |
| Sec-Fetch-Dest | What resource type is requested? | Using dest instead of site for CSRF policy |
Practical policy examples
- Reject cookie-authenticated POST, PUT, PATCH, and DELETE when Sec-Fetch-Site is cross-site unless a valid CSRF token is present.
- Allow cross-site GET only for truly public, idempotent resources.
- Treat same-site differently from same-origin when subdomains have different trust levels.
- Require Sec-Fetch-Site: same-origin for sensitive JSON admin APIs consumed only by your SPA.
- Do not block Sec-Fetch-Site: none for legitimate direct navigations to login pages.
- Log cross-site attempts against authenticated endpoints for monitoring.
- Remember API clients and curl will not send Fetch Metadata unless you emulate it in tests only.
Limits and pitfalls
Sec-Fetch-Site is not authenticated. Attackers controlling a non-browser HTTP client can send same-origin on arbitrary requests. Even in browsers, privacy features and extensions may alter or remove Fetch Metadata.
Confusing same-site with same-origin causes policy gaps: two subdomains on one registrable domain are same-site but not same-origin, which matters when one subdomain hosts user content.
The practical takeaway
Sec-Fetch-Site tells servers whether a request originates from the same origin, the same registrable site, a different site, or no initiator at all. Use it as an early filter against cross-site abuse, always alongside CSRF tokens, cookie attributes, and authorization—not as a standalone guarantee.
Related security terms
Sec-Fetch-Mode
Describes fetch algorithm (navigate, cors), not initiator–target origin relationship.
Sec-Fetch-User
Indicates user-activated navigation, not whether the request is cross-site.
Same-Origin Policy (SOP)
Strict origin equality; Sec-Fetch-Site also models registrable same-site relationships.
Cross-Site Request Forgery (CSRF)
An attack class Sec-Fetch-Site helps detect when combined with other controls.
Frequently asked questions
What is Sec-Fetch-Site in simple terms?
It tells the server how the page that started the request relates to the URL being requested—whether they share the exact origin, are on the same registrable site, are completely different sites, or there was no initiator context.
How is Sec-Fetch-Site different from Sec-Fetch-Mode?
Sec-Fetch-Site is about origin relationship (same-origin, cross-site, and so on). Sec-Fetch-Mode is about how the browser issued the fetch (navigate, cors, no-cors, same-origin, websocket).
How is Sec-Fetch-Site different from Sec-Fetch-User?
Sec-Fetch-Site classifies the initiator–target site relationship for any request that has an initiator. Sec-Fetch-User only appears on navigations and reports whether a user gesture triggered them.
How is Sec-Fetch-Site different from Sec-Fetch-Dest?
Sec-Fetch-Site answers where the request comes from relative to the target. Sec-Fetch-Dest answers what kind of resource is being fetched (document, script, image, and similar).
What does cross-site mean?
cross-site means the initiator and target are not same-site according to the browser’s registrable domain rules—for example app.example.com loading api.other.com.
What does none mean?
none indicates the request has no meaningful initiator context in the usual sense, such as user-typed URLs, bookmarks, or some privacy-preserving navigations.
Can I block CSRF with Sec-Fetch-Site alone?
It is a strong signal—rejecting cross-site POSTs on cookie-authenticated endpoints is a common pattern—but you should still use CSRF tokens, SameSite cookies, and proper authorization because non-browser clients can omit or spoof headers.
References
Explore authoritative guidance and frameworks related to sec-fetch-site.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.