til: Fetch Metadata Request Headers are cool

Cross-Site Request Forgery protections have been on my mind a lot recently and I have been frustrated at how clunky the commonly employed protections are, namely the “double submit” cookie pattern combined with Origin header checks.

Example problems include:

• they require you to manage a server-side secret to generate cryptographically secure random tokens.
• they require external configuration information to operate, namely the server’s origin and whether it is served over HTTPS (this is problematic if your application is sometimes deployed behind a reverse proxy that changes either of these).
• some implementations can be easy to mis-use leading to annoying false positive bugs.[1], [2]

Thankfully browsers have evolved to make the problem of solving Cross-Site Request Forgery much easier with the addition of Fetch Metadata Request Headers. These are HTTP headers that clients send to provide additional context about the request and the origin that initiated it to allow the server to make confident decisions about whether and how it should be processed. An important feature is that these headers are sent with all HTTP requests, regardless of whether they originated from DOM elements, scripts, forms, or direct user navigation. They are also “secure” meaning they cannot be manipulated be Javascript.

There are four new headers in the spec: