Cybersecurity glossary
What is Fetch Metadata?
Learn what Fetch Metadata request headers are, how Sec-Fetch-Site and related fields describe cross-origin context, and how servers use them to block unsafe navigations and CSRF.
Definition
Fetch Metadata is a set of browser-generated HTTP request headers—such as Sec-Fetch-Site, Sec-Fetch-Mode, Sec-Fetch-Dest, and Sec-Fetch-User—that describe how a request relates to the initiating document, helping servers apply context-aware security policies.
Why Fetch Metadata matters
Servers traditionally guessed request intent from Referer, cookies, and custom tokens. Referrers are privacy-tuned and sometimes missing. Tokens require correct framework wiring on every form and API route.
Fetch Metadata gives servers a structured, browser-controlled summary of each request: cross-site or same-origin, navigation or no-cors image, user-initiated or not. That context supports precise allowlists—block cross-site POSTs to admin APIs while still serving cross-origin images.
How Fetch Metadata works
For requests the browser initiates, the user agent attaches Sec-Fetch-* headers derived from the fetching document, request mode, destination, and user activation. Application middleware inspects them before expensive or dangerous handlers run.
User action triggers fetch
A click, form submit, or subresource load starts an HTTP request from a document.
Browser computes metadata
The UA derives Sec-Fetch-Site, Mode, Dest, and User from the request context.
Headers attached automatically
Clients cannot set Sec-Fetch-* from JavaScript; only the browser adds them.
Server policy evaluates
Middleware matches site/mode/dest tuples against allow and deny rules.
Risky cross-site actions blocked
Disallowed combinations return 403 before state change or sensitive reads.
Legitimate traffic proceeds
Same-site navigations, expected embeds, and APIs with proper CORS pass policy.
Core Sec-Fetch headers
Sec-Fetch-Site
Relationship between request initiator and target: same-origin, same-site, cross-site, or none.
Sec-Fetch-Mode
Request mode such as navigate, cors, no-cors, or websocket.
Sec-Fetch-Dest
Destination hint: document, image, script, empty for XHR/fetch, and more.
Sec-Fetch-User
Whether a navigation was activated by user gesture (?1) or not (?0).
cross-site
Indicates the request crosses registrable domains—high signal for CSRF policy.
same-origin
Request target matches the initiator origin; lower risk for same-origin-only endpoints.
Policy patterns by endpoint
| Endpoint | Typical allow | Typical block |
|---|---|---|
| HTML admin pages | Sec-Fetch-Site: same-origin, Mode: navigate | cross-site navigate to sensitive paths |
| JSON mutation API | same-site or same-origin cors with auth | cross-site cors POST without CORS preflight success |
| Public images | cross-site, Dest: image, Mode: no-cors | N/A for read-only static assets |
| Logout / account delete | same-origin navigate with Sec-Fetch-User: ?1 | cross-site requests regardless of cookies |
| Webhooks (non-browser) | No Sec-Fetch headers; separate auth | Do not apply browser metadata rules blindly |
Fetch Metadata checklist
- Protect state-changing routes with metadata policies in addition to CSRF tokens.
- Default deny cross-site Sec-Fetch-Site on admin and account management URLs.
- Allow cross-site image/script/font patterns only on routes meant to be embeddable.
- Log blocked metadata tuples to tune false positives before enforcement.
- Do not trust Sec-Fetch headers from non-browser clients; use separate authentication.
- Combine with SameSite cookies and Origin checks for defense in depth.
- Test payment return URLs and OAuth redirects—they often appear cross-site.
- Document exceptions for CDN health checks and server-to-server traffic without Sec-Fetch.
Limits and pitfalls
Fetch Metadata is not a cryptographic proof. Custom HTTP clients ignore or spoof headers. Policies must assume missing metadata on API traffic that is not browser-initiated.
Overly broad blocks can break legitimate flows: federated login redirects, email links, and partner integrations often arrive as cross-site navigations. Tune allowlists with reporting before hard enforcement.
The practical takeaway
Fetch Metadata lets servers see how the browser classified each request—cross-site or not, navigation or subresource, user-driven or passive. Used well, it stops entire CSRF and cross-site inclusion classes without parsing fragile Referer chains.
Deploy metadata policies on sensitive routes, keep CSRF tokens and SameSite cookies in place, and treat Fetch Metadata as a precise filter on real browser traffic—not a universal gate for every client.
Related security terms
Cross-Site Request Forgery (CSRF)
Attack class servers can narrow with Fetch Metadata-aware allowlists.
Same-Origin Policy (SOP)
Baseline origin model that Fetch Metadata helps servers reason about at request time.
Content Security Policy (CSP)
Client-side policy layer complementary to server-side Fetch Metadata checks.
Referrer Policy
Controls Referer leakage; Fetch Metadata provides additional non-spoofable context in modern browsers.
Frequently asked questions
What is Fetch Metadata in simple terms?
Browsers attach extra headers to requests that say where the request came from and what it is trying to do—like whether it is cross-site navigation or an embedded image. Servers read those hints to allow or block risky patterns.
Which headers are part of Fetch Metadata?
The core set includes Sec-Fetch-Site, Sec-Fetch-Mode, Sec-Fetch-Dest, and Sec-Fetch-User. Sec-Fetch-Storage-Access appears in storage-access contexts. Names and availability evolve with the Fetch spec.
Can attackers forge Sec-Fetch headers?
Malicious non-browser clients can send arbitrary values. Fetch Metadata is trustworthy when sent by conforming browsers on real user traffic. Treat absent or inconsistent headers as out-of-policy for sensitive endpoints.
How does Sec-Fetch-Site help stop CSRF?
State-changing endpoints can reject requests where Sec-Fetch-Site is cross-site while Sec-Fetch-Mode is navigate or cors, indicating the action did not originate as a same-site user gesture in the expected context.
Should Fetch Metadata replace CSRF tokens?
Not alone. Tokens and SameSite cookies remain important. Fetch Metadata is defense in depth that blocks entire classes of cross-site requests in supporting browsers when policies are strict.
Do all browsers send Fetch Metadata?
Modern Chromium, Firefox, and Safari families send them on navigations and subresource requests they initiate. Legacy clients and some automated tools will not. Design policies with a default-deny stance for sensitive routes.
References
Explore authoritative guidance and frameworks related to fetch metadata.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.