Cybersecurity glossary

What is Sec-Fetch-Dest?

Learn what the Sec-Fetch-Dest HTTP request header is, how browsers label fetch destinations, how servers and WAFs use it for policy decisions, and how it fits the Fetch Metadata request headers family.

Web platform securityUpdated July 22, 2026
Also known asSec-Fetch-Dest headerFetch destination metadatasec-fetch-dest request header

Definition

Sec-Fetch-Dest is a Fetch Metadata request header set by browsers that indicates the destination of a request—such as document, script, image, or empty—so servers can distinguish navigation from subresource loads and apply appropriate security policies.

Why Sec-Fetch-Dest matters

Servers historically struggled to tell a top-level navigation from a cross-site fetch POST or an <img> beacon. That ambiguity helps CSRF, cross-site data exfiltration, and JSON endpoints accidentally exposed to simple GET embedding.

Sec-Fetch-Dest is one of the Fetch Metadata headers browsers attach automatically. It labels the request’s destination so applications, APIs, and WAFs can allow document navigations while rejecting empty cross-site posts to state-changing routes.

How Sec-Fetch-Dest works

1

Browser initiates a request

Navigation, script load, image fetch, or fetch() API call starts.

2

Client sets Sec-Fetch-Dest

The user agent assigns a destination token such as document, script, or empty.

3

Companion metadata is added

Sec-Fetch-Mode, Sec-Fetch-Site, and sometimes Sec-Fetch-User accompany Dest.

4

Server evaluates the tuple

Rules may allow same-site document navigations but block cross-site empty POSTs.

5

Request proceeds or is rejected

A 403 or early drop stops abuse without breaking legitimate browser traffic patterns.

Common destination values

document

Top-level navigation or iframe document loads—the classic page view case.

iframe

Embedded document requests where framing policies also apply.

script

JavaScript resources loaded by script tags or module graphs.

style

CSS stylesheets linked from markup.

image

Images, icons, and tracking pixels requested as image destinations.

empty

Often fetch/XHR calls—high-signal for API CSRF hardening when combined with Site and Mode.

Policy patterns using Fetch Metadata

Route typeTypical allow signalTypical block signal
HTML page GETSec-Fetch-Dest: document with expected Sitedocument from unexpected cross-site embed contexts
JSON mutation APIempty + cors/same-origin from first-party SPAempty + cross-site on cookie-authenticated POST
Static asset CDNscript, style, image, font destinationsdocument navigations to non-HTML objects
Admin export downloaddocument or empty with same-origin Sitecross-site image or script destinations hitting export URLs

Security checklist

  • Evaluate Sec-Fetch-Dest together with Sec-Fetch-Mode, Sec-Fetch-Site, and Sec-Fetch-User—not in isolation.
  • Block state-changing requests when Dest is empty, Site is cross-site, and Mode is cors on cookie-auth APIs.
  • Do not rely on Fetch Metadata alone; keep CSRF tokens and SameSite cookies for defense in depth.
  • Expect missing headers from bots, monitors, and native apps; fail open or use separate auth paths for those clients.
  • Log rejected metadata tuples temporarily when tuning rules to avoid false positives.
  • Align CDN and origin WAF rules so metadata checks happen before expensive application work.
  • Test iframe and prefetch edge cases; some destinations differ from intuitive page navigations.
  • Document allowed tuples per API surface so security and frontend teams share one contract.

Limits and pitfalls

Fetch Metadata is a browser-only signal. curl, server-side jobs, and compromised native clients omit Sec-Fetch-Dest entirely. Treat absence as unknown, not automatically malicious—unless the route is browser-exclusive.

Overly aggressive blocking can break legitimate flows: payment redirects, OAuth returns, RSS readers, and certain prefetch optimizations may present surprising combinations during rollout.

Header values evolve with the spec. Hard-coded allowlists need maintenance when new destination tokens appear for emerging resource types.

The practical takeaway

Sec-Fetch-Dest tells servers what kind of resource a browser request targets. Combined with other Fetch Metadata headers, it is a practical layer for reducing CSRF and cross-site abuse on modern browsers.

Use it to complement—not replace—token-based CSRF defenses and strong authentication. Tune rules with real traffic, and assume non-browser clients will always bypass the signal.

Related security terms

Frequently asked questions

What is Sec-Fetch-Dest in simple terms?

It is a header the browser adds to say what kind of thing the request is for—a full page navigation, a script, an image, a fetch call, and so on. Servers can use that signal in security rules.

Can JavaScript set Sec-Fetch-Dest?

No. Sec-Fetch-* headers are forbidden request headers controlled by the browser. Scripts cannot spoof them through normal fetch APIs.

What does dest empty mean?

empty often indicates a fetch or XHR-style API call rather than a navigation or classic subresource tag. Combined with Sec-Fetch-Mode and Sec-Fetch-Site, it helps spot cross-site POST abuse.

Should APIs block requests without Sec-Fetch-Dest?

Non-browser clients omit these headers. Use Fetch Metadata as a browser-specific hardening layer alongside CSRF tokens and proper auth—not as the only control.

How is Sec-Fetch-Dest different from Sec-Fetch-Mode?

Dest describes what the request is for (document, script, image). Mode describes how it is being fetched (navigate, cors, no-cors, same-origin).

Do all browsers send Sec-Fetch-Dest?

Modern Chromium, Firefox, and Safari families generally send Fetch Metadata for navigations and fetches they initiate. Legacy clients and many bots will not.

References

Explore authoritative guidance and frameworks related to sec-fetch-dest.

Explore every security definition

Return to the glossary to search by term, alias, starting letter, or security category.

Browse glossary