Response headers are only one-way? We never see x-csrftoken again.

[gnat]

A bit of confusion as to how this middleware is intended to work.

Response headers are one-way, correct? So how is x-csrftoken ever supposed to be seen by the server again without the client explicitly sending it?

Sending an invisible field with POST data makes sense, a custom header does not? Am I missing something?

[frankie567]

Well, actually the client must explicitly set the x-csrftoken header when making a request; rather than sending a hidden form value. At the same time, the browser will automatically send the cookie containing the value in the request. This is why it's called the "Double Submit Cookie". Then, the server will be able to compare the value in x-csrftoken and in the cookie to be sure they match.

You can read more about this here: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#double-submit-cookie

[gnat]

I see. So this middleware is intended to be used with an AJAX call, because setting a request header is not possible in HTML?

Please clarify if this is incorrect. Otherwise, thanks for the nudge in the right direction.

[frankie567]

Indeed, it's intended to be used with REST API called from the browser with AJAX/XHR requests where you can set headers manually.

[frankie567]

For a middleware working more traditionally with a hidden form field, you can try simonw/asgi-csrf 😉

[gnat]

For future readers needing to use the POST method to do CSRF in Starlette, this implemention is also good and small: https://github.com/piccolo-orm/piccolo_api/blob/master/piccolo_api/csrf/middleware.py