Skip to content

Archive

Fetch Metadata

7 articles
Cybersecurity 23 Sep 2026 5 min read

Fetch Metadata Adds Request Context to Server-Side Policy

Fetch Metadata Adds Request Context to Server-Side Policy A server often sees the same authenticated cookie on requests created by very different browser actions. A form submitted from another site, a same-origin API call, an image load, and a top-level navigation can all reach the same host. Cookies alone do not describe that request context. Fetch Metadata adds browser-generated request headers that describe where a request came from and how the browser intends to use the response. A server can incorporate those signals into an isolation policy before application logic handles a sensitive route.

Cybersecurity 22 Sep 2026 4 min read

Fetch Metadata Lets Servers Filter Cross-Site Requests

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.

Cybersecurity 21 Sep 2026 5 min read

Fetch Metadata Headers Filter Cross-Site Requests

Fetch Metadata Headers Filter Cross-Site Requests A web server often receives requests that look valid at the HTTP layer even when they originated from an unrelated site. Cookies may accompany those requests, and a state-changing endpoint can be exposed if its defenses treat every browser request as equally trustworthy. Fetch Metadata gives the server additional context. Supporting browsers attach Sec-Fetch-* request headers that describe the relationship between the initiator and target, the request mode, the destination, and whether navigation resulted from direct user activation. A server can use that context as an early resource-isolation gate.

Cybersecurity 20 Sep 2026 6 min read

Fetch Metadata Headers Gate Cross-Site Requests

Fetch Metadata Headers Gate Cross-Site Requests A web server often receives enough HTTP information to route a request but not enough to tell what browser context produced it. A GET might be a top-level navigation, an image load, or a JavaScript fetch. A POST might come from the application’s own page or from a form hosted on another site. Fetch Metadata adds browser-generated request headers that describe that context. Sec-Fetch-Site reports the relationship between the initiator and target, while Sec-Fetch-Mode, Sec-Fetch-Dest, and in some cases Sec-Fetch-User describe the request mode, destination, and user activation. A server can use those signals to reject request shapes that an endpoint has no reason to accept.

Cybersecurity 19 Sep 2026 6 min read

Fetch Metadata Headers Define a Server-Side Cross-Site Request Boundary

A browser can send an authenticated request to a site from a document hosted somewhere else. Cookies may accompany that request according to their cookie attributes, while the same-origin policy can still prevent the initiating page from reading the response. For a server, that distinction matters: blocking response access does not necessarily stop a cross-site request from reaching an endpoint. Fetch Metadata adds request context to this boundary. Supporting user agents attach Sec-Fetch-* request headers that describe relationships and request properties the server can evaluate before application logic performs a sensitive action. A policy can reject a request because it is cross-site, while preserving selected navigation or public-resource flows.

Cybersecurity 17 Sep 2026 8 min read

Fetch Metadata Exposes Browser Request Context at the Server Boundary

Fetch Metadata Exposes Browser Request Context at the Server Boundary A state-changing endpoint can receive two HTTP requests with the same method, path, cookies, and body while the browser reached them through very different contexts. One may come from the application’s own document. The other may have been triggered by a foreign site through a form, image load, navigation, or another browser mechanism that permits a request without granting the initiating page access to the response.

Cybersecurity 15 Sep 2026 6 min read

Fetch Metadata Makes Cross-Site Request Context Visible

Fetch Metadata Makes Cross-Site Request Context Visible A server receiving an authenticated HTTP request often sees valid cookies, a plausible path, and a method that the application accepts. Those facts do not reveal whether the request began inside the application’s own page or was triggered by a document on another site. For endpoints that change state, that missing context has long been central to cross-site request forgery defenses. Fetch Metadata request headers expose part of the context already known to the browser. Headers such as Sec-Fetch-Site, Sec-Fetch-Mode, Sec-Fetch-Dest, and Sec-Fetch-User describe relationships and properties surrounding a request. A server can use those signals to reject request patterns that do not belong to its application architecture.