How Fetch Metadata Helps Servers Reject Attacks

A server receives more than a URL when a browser makes a request. It also receives method, cookies, content type, and other headers. Yet many attacks succeed because the server cannot easily tell why the request was made. Did a person click a link on the same site, did JavaScript call an API, or did an unrelated page cause the browser to submit a cross-site request?

Fetch Metadata request headers provide that missing context. They let a browser describe the relationship between the page initiating a request and the destination, the request mode, the type of resource being requested, and whether a navigation was triggered by the user. A server can use those signals to reject requests that do not fit an endpoint's intended use.

The four main context signals

The most widely used Fetch Metadata headers begin with Sec-Fetch-. The prefix is important: browsers control these headers, and web page JavaScript cannot freely forge them.

• Sec-Fetch-Site describes the relationship between the initiator and destination: same-origin, same-site, cross-site, or none.
• Sec-Fetch-Mode describes the fetch mode, such as navigation, CORS, no-CORS, or same-origin.
• Sec-Fetch-Dest identifies the intended destination, such as document, image, script, style, iframe, or empty for many programmatic requests.
• Sec-Fetch-User appears on certain navigations activated by a user, helping distinguish a direct action from an automatic load.

The W3C Fetch Metadata specification defines these signals. MDN's Fetch Metadata guide explains how servers can use them in resource isolation policies.

Origin relationships carry different risk

same-origin means the request began from the same scheme, host, and port. same-site is broader: two origins may share the same registrable site while differing by subdomain or, in some contexts, scheme. cross-site means the initiator belongs to another site. none commonly represents user-initiated contexts without a web origin, such as entering an address or opening a bookmark.

Those categories should not be treated as universal trust scores. A vulnerable sibling subdomain can make some same-site requests dangerous, and a legitimate cross-site integration may be essential. The value is context: the server can compare the request with what a particular route is supposed to accept.

Our explanation of the same-origin policy covers the underlying browser boundary and why “site” and “origin” are related but different concepts.

A resource isolation policy in practice

Consider an account endpoint that changes a delivery address. It is designed for requests originating inside the application, not for form submissions manufactured by unrelated websites. A simple server policy can deny state-changing cross-site requests before the application processes them.

Static images may have a different rule because cross-site embedding is expected. A public document route may allow top-level navigations, particularly when Sec-Fetch-Mode is navigate and the request represents a user action. A JSON API may accept only same-origin calls plus a documented mobile-client path.

The policy belongs at a layer that sees every relevant request: a reverse proxy, edge worker, middleware component, or application framework. It should be expressed per class of resource rather than as one blunt rule for the whole domain.

How the headers help against common attacks

Cross-site request forgery relies on a hostile page causing a browser to send an authenticated request to another site. Cookies may accompany that request even though the user did not intend the action. Fetch Metadata can expose the cross-site context and let the destination reject it.

Cross-site script inclusion and information leaks can exploit resources that return sensitive, executable, or distinguishable responses when embedded by another origin. Destination and site signals help a server reserve those resources for their intended contexts.

The headers can also reduce accidental exposure. If an endpoint was built only for same-origin application code, rejecting other contexts makes that assumption enforceable instead of leaving it as undocumented developer knowledge.

Fetch Metadata is not authentication

A request marked same-origin is not automatically authorized. An attacker who compromises application JavaScript or finds an injection flaw can operate from the allowed context. Servers still need sessions, access control, input validation, and protection against cross-site scripting.

Fetch Metadata also should not replace CSRF tokens where strong transaction protection is required. It is a complementary signal that can block broad classes of unwanted traffic early. SameSite cookies, Origin or Referer validation where appropriate, and deliberate API design remain important.

The Referrer header may reveal a URL or origin, depending on policy. Fetch Metadata is different: it provides coarse, structured context without requiring the full referring address. That makes it useful for security decisions while limiting unnecessary URL disclosure.

Plan for clients that do not send the headers

Current browsers support the core headers broadly, but a server may also receive requests from older browsers, command-line tools, native applications, webhooks, health checks, and bots. Treating every missing header as hostile can break legitimate traffic.

A safer rollout begins in observation mode. Log the values, route, method, client type, and proposed decision without blocking. Identify exceptions, document why each exists, and test redirects, sign-in flows, payment callbacks, identity providers, and cross-origin APIs.

When enforcement starts, protect the clearest high-risk routes first. A state-changing browser endpoint has a stronger case for rejecting cross-site requests than a public image. Keep a measurable fallback for clients that legitimately lack the headers, such as conventional CSRF validation or authenticated API credentials.

Build a policy around intent

• Classify endpoints as navigations, static resources, browser APIs, or non-browser integrations.
• Define which origin relationships, modes, methods, and destinations each class expects.
• Log would-be denials before enforcing them.
• Allow explicit exceptions for identity, payment, webhook, and partner flows.
• Combine the policy with authentication, authorization, CSRF defenses, and a strong Content Security Policy.
• Review rules when application architecture or embedded services change.

Fetch Metadata turns browser knowledge into server-side evidence. The headers do not prove that a request is good, but they reveal when its context contradicts the purpose of a resource. Used carefully, that makes many cross-site attacks easier to reject before they reach sensitive application logic.

Browse with more intention

Noorani brings prayer times, Qibla, tracker blocking, and privacy into one calm desktop browser built for how Muslims live online.

Download Noorani