Cookie tokens in API methods

[PizieDust]

Some API endpoints (particularly those which use multipart/form-data still check for a csrf cookie even when it's purely an API call.
For API calls, passing an empty csrf cookie will work as long as the Authorization header is correct. The JSON parsing strictly checks for the presence of molly_csrf field but discards it later on for API functions.

[hannesm]

Could you explain what the purpose of the CSRF is (maybe a link to some best practises guide is sufficient), and when & where they should be checked? From your description above, I've no idea whether they should be checked, and we don't do this -- or whether they're superfluous.

[PizieDust]

So we can find some valuable information here: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html

For us, the CSRF token (in request we call it molly_csrf is the cookie that we use for UI pages via the browser. For every POST request, if we don't see this cookie then we automatically reject the request with the assumption that the request has been tampered with.

For purely interactions via the API, we don't have a browser session and hence no cookie, what we check is the api token.
Now, we have a setup such that the UI's when performing actions collect the data and send it via the api routes, and for some request which deal with streaming, we use multipart-form/data.
So, when we are working with the browser, we send this molly_csrf along in the multipart request.
For API, this molly_csrf is not needed, but our logic still checks for it, although it doesnt do anything with the value. For API we only care if there is an Authorization header with a valid Bearer token.

This issue is a reminder to refactor how we handle csrf such that when it's a purely API call (like with curl), we don't have to pass an empty molly_csrf.