Protects unsafe same-origin exchanges only: a safe method changes nothing on the server, and a cross-origin target
is no place to disclose the token to. An exchange stating its method in lowercase is protected as one stating it in
uppercase, as the platform normalises the standard methods before the exchange is inspected.
The token is read from the document on every exchange, rather than once when the middleware is created, so that a
token renewed or rotated mid-session is echoed as it stands without the client being assembled again.
An exchange stating a field of its own is left as it is, leaving a call site taking care of the token on its own
terms in charge; one running in a document stating no token, or an empty one, is sent unprotected, for the server
to refuse; one attempted outside a browser, where no document is there to state a token, is rejected without being
sent.
Important
This is the client half of the protection only: the server completes it by refusing an unsafe request whose field
doesn't match the cookie it stated. On a server that doesn't check, echoing the token protects nothing.
The server is expected to bind the token to the session, as signed double-submit prescribes: where it merely
compares the cookie to the header, whoever controls a sibling subdomain plants a token of their choosing under the
parent domain and echoes it back.
An application and an endpoint on separate origins, as app.example.com and api.example.com are, draw no
protection from this scheme: the domain-scoped session cookie is still sent while the field is not, so the server
refuses every unsafe exchange, and the deployment calls for a scheme of its own.
Creates an XSRF protection middleware.
Protects unsafe same-origin exchanges only: a safe method changes nothing on the server, and a cross-origin target is no place to disclose the token to. An exchange stating its method in lowercase is protected as one stating it in uppercase, as the platform normalises the standard methods before the exchange is inspected.
The token is read from the document on every exchange, rather than once when the middleware is created, so that a token renewed or rotated mid-session is echoed as it stands without the client being assembled again.
An exchange stating a field of its own is left as it is, leaving a call site taking care of the token on its own terms in charge; one running in a document stating no token, or an empty one, is sent unprotected, for the server to refuse; one attempted outside a browser, where no document is there to state a token, is rejected without being sent.
This is the client half of the protection only: the server completes it by refusing an unsafe request whose field doesn't match the cookie it stated. On a server that doesn't check, echoing the token protects nothing.
The server is expected to bind the token to the session, as signed double-submit prescribes: where it merely compares the cookie to the header, whoever controls a sibling subdomain plants a token of their choosing under the parent domain and echoes it back.
An application and an endpoint on separate origins, as
app.example.comandapi.example.comare, draw no protection from this scheme: the domain-scoped session cookie is still sent while the field is not, so the server refuses every unsafe exchange, and the deployment calls for a scheme of its own.