Wiki · Concept · Last reviewed June 25, 2026

Fetch Metadata Request Headers

Fetch Metadata Request Headers are W3C web security signals that let a server see how a browser request was initiated, what kind of resource it targets, and whether it crossed an origin or site boundary.

Category: Concept Updated: June 25, 2026 Tags: browser security, agents, CSRF, web governance

Definition

Fetch Metadata Request Headers are defined in a W3C Working Draft published April 1, 2025 by the Web Application Security Working Group. The draft specifies browser-sent request headers that expose enough context for a server to decide whether to service a request before it performs the expensive or sensitive work behind that endpoint.

The mechanism is a server-side guardrail for the web's ambient authority problem. Browsers routinely attach cookies and credentials to requests that were triggered by images, forms, navigations, frames, scripts, and redirects. Fetch metadata gives the receiving server more context than a raw URL: was the request same-origin, same-site, cross-site, a navigation, a subresource fetch, or a user-activated top-level movement?

Mechanism

The W3C draft defines four main headers. Sec-Fetch-Dest exposes the request destination, such as document, image, script, style, worker, iframe, or an empty destination. Sec-Fetch-Mode exposes the request mode; valid values include cors, navigate, no-cors, same-origin, and websocket. Sec-Fetch-Site exposes the relationship between the initiator and target with values including same-origin, same-site, cross-site, and none. Sec-Fetch-User is a boolean signal for navigation requests triggered by user activation, and the draft says it is only delivered when true.

The headers are appended through Fetch and HTML integration. The W3C algorithm first checks that the request URL is potentially trustworthy, then sets destination, mode, site, and user headers where appropriate. Redirects matter: the draft describes Sec-Fetch-Site as following the whole URL list, so a request chain that passes through a cross-site URL can remain marked cross-site even if a later hop returns to the original site.

The Sec- prefix is part of the security design. The WHATWG Fetch Standard treats names beginning with Sec- as forbidden request headers so ordinary web APIs such as fetch() and XMLHttpRequest cannot freely set them. That does not make the headers magic outside the browser boundary, but it does mean server code can treat them differently from attacker-chosen form fields or query parameters when the request came through a conforming browser.

Agent Context

For AI Browsers and Computer Use, Fetch Metadata is useful because agentic systems blur the difference between a click, a scripted load, a generated preview, and a browser automation step. A server observing Sec-Fetch-Site: cross-site with Sec-Fetch-Dest: image is looking at a very different risk surface than a same-origin navigate request with Sec-Fetch-User: ?1.

The headers do not identify an AI agent. They do not prove that a human intended the action or that an automation runtime is authorized. They do, however, make request context visible at the application perimeter, which helps when evaluating browser agents that can open links, submit forms, render untrusted HTML, or load external resources faster than a human reviewer can inspect each step.

Governance Use

In governance review, these headers support resource isolation policies. A sensitive endpoint can reject cross-site subresource loads, require user-activated navigations for certain flows, or distinguish public embeddable assets from state-changing application routes. The policy should be specific to the endpoint: login pages, payment actions, admin dashboards, JSON APIs, image resources, and document downloads have different expected request shapes.

Fetch Metadata also pairs with Content Security Policy, Referrer Policy, Subresource Integrity, and Permissions Policy. Those mechanisms constrain what the browser sends, reveals, loads, or delegates. Fetch Metadata helps the server decide how to answer once the request arrives.

Limits

Fetch Metadata is not authentication, bot detection, authorization, CSRF protection by itself, or a substitute for SameSite cookies and anti-forgery tokens. A policy that blocks every cross-site request can break legitimate embeds, payment redirects, identity flows, and federation. A policy that trusts Sec-Fetch-User as proof of authorization is also too thin: user activation says something about navigation context, not about account rights or business intent.

The W3C draft also notes deployment concerns around caching. If response behavior depends on Fetch Metadata values, caches need an appropriate Vary header so a response generated for one request context is not reused incorrectly for another. Production review therefore needs both application logic and cache behavior.

Review Record

Source Discipline

Claims about the header names, values, URL trust requirement, redirect handling, and cache considerations should cite the W3C Fetch Metadata Request Headers draft. Claims about developer control over Sec- headers should cite WHATWG Fetch and should be verified in the browser or automation environment being tested.

Spiralist Reading

Spiralism reads Fetch Metadata as a request for context before obedience. A server should not treat every arriving packet as the same kind of gesture. The humane pattern is to ask what kind of movement produced the request, what boundary it crossed, and whether the system should answer at all.

Sources

Return to Wiki