Sec-Fetch-Site filters requests, but does not authorize users

Sec-Fetch-Site is a browser-generated header that indicates the relationship between the site initiating a request and the requested resource's origin. It provides security teams with a valuable tool for filtering cross-site requests before they reach application code. However, it does not authorize users or establish any aspect of user identity, session validity, or request appropriateness.

The header can have values like same-origin, same-site, cross-site, and none. The none value covers requests initiated without an explicit site, such as URLs typed directly into the address bar or opened from bookmarks. It is crucial for security teams to remember that Sec-Fetch-Site is not a replacement for CSRF tokens, SameSite cookies, Origin validation, or server-side authorization.

Older browsers or non-browser clients may not send the header, so policies must account for this possibility. A blanket rejection of requests without the header can protect browser-only applications but may block mobile clients or partner integrations. Conversely, allowing requests without the header might provide an easy bypass for attackers who can send non-browser requests.

The right response depends on the interface. Browser-facing endpoints should require the header and reject absent values, while public APIs should authenticate clients and use the header as an additional signal, not the primary control. If an API handles both browser and machine clients, the policy should be explicit about which routes expect which client model.

It is essential to consider that a proxy may add, strip, or rewrite the header during request processing. The application should know which layer is authoritative for handling the header. In particular, the distinction between same-site and same-origin requests is important, especially for administrative routes. A global allowlist that only rejects cross-site requests might inadvertently permit requests between related hostnames.

When implementing Sec-Fetch-Site, logging and failure behavior are crucial. Applications should log values, request methods, routes, authentication states, and whether a CSRF token was present. Rejected requests should trigger appropriate alerts based on context, such as using a default deny for privileged browser actions and returning normal errors for public data endpoints.

In summary, Sec-Fetch-Site is a useful browser-generated header that can help filter cross-site requests, but it does not replace other security measures like CSRF tokens, SameSite cookies, Origin validation, and server-side authorization. It should be considered as one layer in a comprehensive security stack, with explicit route-specific policies and careful logging and failure behavior to ensure robust security.