🎉 Requestly joins BrowserStack to build the future of application testing. Read more

HTTP Headers

Sec Fetch Dest

HTTP Header

The HTTP Sec-Fetch-Dest fetch metadata request header indicates the request’s destination. That is the initiator of the original fetch request, which is where (and how) the fetched data will be used.

This feature enables servers to decide whether to process a request based on whether it aligns with the expected usage. For instance, a request indicating an audio destination should seek audio data, rather than other types of resources such as documents containing sensitive user information.

The header type is classified as a Fetch Metadata Request Header. It is a forbidden request header that uses the Sec- prefix. Unlike some other headers, it is not considered a CORS-safelisted request header, meaning it is subject to specific restrictions and controls.

Syntax

Sec-Fetch-Dest: audio
Sec-Fetch-Dest: audioworklet
Sec-Fetch-Dest: document
Sec-Fetch-Dest: embed
Sec-Fetch-Dest: empty
Sec-Fetch-Dest: fencedframe
Sec-Fetch-Dest: font
Sec-Fetch-Dest: frame
Sec-Fetch-Dest: iframe
Sec-Fetch-Dest: image
Sec-Fetch-Dest: manifest
Sec-Fetch-Dest: object
Sec-Fetch-Dest: paintworklet
Sec-Fetch-Dest: report
Sec-Fetch-Dest: script
Sec-Fetch-Dest: serviceworker
Sec-Fetch-Dest: sharedworker
Sec-Fetch-Dest: style
Sec-Fetch-Dest: track
Sec-Fetch-Dest: video
Sec-Fetch-Dest: webidentity
Sec-Fetch-Dest: worker
Sec-Fetch-Dest: xslt

Directives

Directives

Directives

Note:
These directives correspond to the values returned by Request.destination.

The destination is audio data. This might originate from an HTML <audio> tag.

The destination is data being fetched for use by an audio worklet. This might originate from a call to audioWorklet.addModule().

The destination is a document (HTML or XML), and the request is the result of a user-initiated top-level navigation (e.g., resulting from a user clicking a link).

The destination is embedded content. This might originate from an HTML <embed> tag.

The destination is the empty string. This is used for destinations that do not have their own value. For example: fetch(), navigator.sendBeacon(), EventSource, XMLHttpRequest, WebSocket, etc.

The destination is a fenced frame.

The destination is a font. This might originate from CSS @font-face.

The destination is a frame. This might originate from an HTML <frame> tag.

The destination is an iframe. This might originate from an HTML <iframe> tag.

The destination is an image. This might originate from an HTML <img>, SVG <image>, CSS background-image, CSS cursor, CSS list-style-image, etc.

The destination is a manifest. This might originate from an HTML <link rel=manifest>.

The destination is an object. This might originate from an HTML <object> tag.

The destination is a paint worklet. This might originate from a call to CSS.PaintWorklet.addModule().

The destination is a report (for example, a content security policy report).

The destination is a script. This might originate from an HTML <script> tag or a call to WorkerGlobalScope.importScripts().

The destination is a service worker. This might originate from a call to navigator.serviceWorker.register().

The destination is a shared worker. This might originate from a SharedWorker.

The destination is a style. This might originate from an HTML <link rel=stylesheet> or a CSS @import.

The destination is an HTML text track. This might originate from an HTML <track> tag.

The destination is video data. This might originate from an HTML <video> tag.

The destination is an endpoint associated with verifying user identity. For example, it is used in the FedCM API to verify the authenticity of identity provider (IdP) endpoints, guarding against CSRF attacks.

The destination is a Worker.

The destination is an XSLT transform.

Example

A cross-site request generated by an <img> element would result in a request with specific HTTP request headers. Notably, the destination is image.

Example of such headers:

Sec-Fetch-Dest: image
Sec-Fetch-Mode: no-cors
Sec-Fetch-Site: cross-site

How to Modify Header using Requestly

Requestly is a powerful Chrome extension that allows you to modify HTTP headers, including the Sec-Fetch-Dest header. This is especially useful for testing how your application handles different types of resource requests during development or debugging. Steps to Modify the Sec-Fetch-Dest Header:

  1. Install and open the Requestly Chrome extension. You can find it on the Chrome Web Store.
  2. Create a new rule: Click on “Create Rule” and choose “Modify Headers” from the list of available rule types.
  3. Add a new header modification:
    • Under “Action”, select “Add” or “Override”.
    • In the “Header Name” field, enter Sec-Fetch-Dest.
    • In the “Header Value” field, enter your desired destination type (e.g., document, image, script).
  4. Set the URL condition: Specify the URL or pattern where this header change should apply (e.g., https://your-api.com/*).
  5. Save the rule.

Once set up, Requestly will inject the specified Sec-Fetch-Dest header into all matching requests, helping you simulate different resource requests and analyze how your server or application responds to them. Modifying the Sec-Fetch-Dest header helps you test how your web server or application reacts to different types of resource requests, like images, scripts, or documents. This can be important for debugging security policies or optimizing resource handling.