Understanding Fetch Metadata Request Headers (Sec-Fetch-*) and Their Security Implications

If you inspect network requests in Chrome 76+ you will see several request headers that start with Sec-Fetch , such as when requesting https://www.baidu.com/ . These headers are part of the Fetch Metadata Request Headers draft, automatically added by the browser and marked as forbidden for modification.

Fetch Metadata headers provide metadata about a request, allowing the server to make fine‑grained decisions about its legitimacy, thereby improving web security by helping to block illegal or malicious requests.

Fetch Metadata Request Headers

Published as a draft in 2019, these headers are still under development and not universally supported. They are added by the browser and omitted when a resource is loaded from the local cache.

Why They Matter

Modern web security has evolved from same‑origin policies to CSP and now to Fetch Metadata, giving servers concrete data to distinguish legitimate traffic from CSRF, XSSI, and other attacks.

Sec-Fetch-Dest

Meaning: Indicates the destination type of the request (how the fetched data will be used). Possible values: document , script , style , image , etc.

Sec-Fetch-Mode

Meaning: Describes the request mode. Possible values: cors , no-cors , same-origin , navigate , websocket . The navigate mode is used for top‑level page navigations, while cors and no-cors affect cross‑origin resource sharing.

Sec-Fetch-Site

Meaning: Describes the relationship between the request initiator and the target resource. Possible values: cross-site , same-origin , same-site , none . The article includes a detailed table showing how different origin combinations evaluate to true or false for the same-site check.

Redirect chains can change the value; several examples illustrate how same-origin , same-site , and cross-site are derived after redirects.

Sec-Fetch-User

Meaning: Boolean indicating whether the navigation was user‑initiated ( ?1 ) or not ( ?0 ). It is only sent with navigation requests such as document , embed , frame , iframe , or object .

Security Policy Example

Below is a Python‑style policy that accepts requests based on the presence and values of the Fetch Metadata headers:

# Reject cross‑origin requests to protect from CSRF, XSSI & other bugs
def allow_request(req):
    # Allow requests from browsers which don't send Fetch Metadata
    if not req['sec-fetch-site']:
        return True
    # Allow same‑origin, same‑site and navigation‑initiated requests
    if req['sec-fetch-site'] in ('same-origin', 'same-site', 'none'):
        return True
    # Allow simple top‑level navigations (GET) from anywhere
    if req['sec-fetch-mode'] == 'navigate' and req.method == 'GET':
        return True
    return False

The policy also notes that browsers that do not support Sec-Fetch-* should be allowed by default.

Vary Header Considerations

When using Fetch Metadata, the Vary response header must include the relevant Sec-Fetch-* fields (e.g., Vary: Accept-Encoding, Sec-Fetch-Site ) so that caches store separate variants for requests with and without those headers.

References

https://developer.mozilla.org/zh-CN/docs/Web/API/Request/mode https://fetch.spec.whatwg.org/#concept-request-mode https://web.dev/fetch-metadata/ https://w3c.github.io/webappsec-fetch-metadata/#intro