Fetch Metadata Lets Servers Filter Cross-Site Requests

A server often receives enough HTTP data to process a request but not enough context to classify the browser action that produced it. Fetch Metadata request headers add that context. Supporting browsers send Sec-Fetch-* fields that describe the relationship between the initiator and target, the request mode, the destination, and whether a navigation was triggered by a user activation.

These headers can support a resource-isolation policy at the server. An endpoint intended only for same-origin application traffic can reject requests whose metadata shows an unexpected cross-site context before application logic handles them.

Sec-Fetch-Site describes the initiator relationship

Sec-Fetch-Site is commonly the first policy input. Its values describe the relationship between the request initiator and the requested resource:

same-origin
same-site
cross-site
none

same-origin is the narrowest relationship. same-site covers requests whose origins differ but qualify as the same site. cross-site identifies a request crossing the site boundary. none is used for requests that are not associated with an initiating origin in the usual way, including certain user-initiated navigations.

A sensitive endpoint can use this signal to reject cross-site requests when cross-site use is not part of its contract.

if Sec-Fetch-Site == cross-site:
    reject unless endpoint explicitly permits it

That rule is a policy example, not a universal configuration. Public resources, federated flows, webhooks, and endpoints intentionally reached from other sites can require different treatment.

Mode and destination refine the request context

Sec-Fetch-Mode reflects the request mode, with values such as navigate, cors, no-cors, and same-origin. Sec-Fetch-Dest describes the request destination, such as document, image, script, or empty.

Together, these fields let a server distinguish request shapes that might otherwise target the same URL space.

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

An endpoint that returns private JSON has little reason to accept an image-style cross-site request. Rejecting a context that cannot be a legitimate application path reduces exposure to browser-driven cross-site request patterns.

The metadata does not describe the business identity of the caller. Authentication and authorization still decide which principal may access a resource.

Navigations need deliberate treatment

Top-level navigation is a normal cross-site operation on the web. A blanket rule that rejects every cross-site request can therefore block valid entry points.

Sec-Fetch-Mode: navigate identifies navigation mode, while Sec-Fetch-User: ?1 can indicate that a navigation request was triggered by user activation. A policy can account for those signals when an application intentionally accepts user-driven navigation from external sites.

For example, a public HTML entry route may permit navigation while a state-changing API route rejects cross-site traffic. Keeping those decisions per endpoint avoids turning Fetch Metadata into an indiscriminate site-wide switch.

The headers are signals, not authentication credentials

Fetch Metadata headers use the Sec- prefix and are forbidden request-header names for web content APIs, which prevents ordinary page script from setting them directly through interfaces such as fetch(). That browser property makes the fields useful as request-context signals.

They still do not replace credentials, CSRF defenses, origin validation where required, or server-side authorization. A non-browser client is outside the browser enforcement model and can construct HTTP requests independently.

A server should therefore treat Fetch Metadata as an additional browser-facing boundary. It narrows accepted request contexts; it does not establish caller identity.

Missing metadata needs an explicit policy

Not every request reaching an application is guaranteed to carry Fetch Metadata headers. Compatibility paths, non-browser clients, intermediaries, and deployment constraints can produce requests without the fields a policy expects.

The application must decide what absence means for each endpoint. A staged rollout can log missing or rejected contexts before enforcement, then tighten routes whose legitimate traffic patterns are established.

metadata present -> evaluate policy
metadata absent  -> explicit compatibility decision

Silently treating absence as equivalent to same-origin weakens the boundary because the two states carry different evidence.

Policy belongs near the endpoint contract

A useful Fetch Metadata policy starts from permitted request contexts rather than from a single global deny rule. Static public assets, HTML navigation, authenticated APIs, upload endpoints, and cross-origin integration routes have different contracts.

Middleware can encode shared defaults while retaining route-level exceptions. The important constraint is that exceptions remain explicit and narrow. An exception added for one integration should not open unrelated application endpoints to the same cross-site context.

Logging rejected values during deployment also gives operators concrete evidence about affected traffic. Useful fields include the route, method, Sec-Fetch-Site, Sec-Fetch-Mode, and Sec-Fetch-Dest, while normal log hygiene still applies to sensitive request data.

Fetch Metadata adds context before application work

The main value of Fetch Metadata is placement. The browser supplies request context, and the server can evaluate that context before expensive or sensitive endpoint behavior proceeds.

That boundary is strongest when its role stays specific: reject browser request contexts that the endpoint does not intend to serve, preserve explicit exceptions for valid cross-site flows, and keep identity and authorization checks independent. Used that way, Sec-Fetch-* headers add a compact isolation layer without pretending to be a complete access-control system.