I am designing a RESTful API which is to be accessible from a web browser. The API is protected by Basic authentication.
I understand the concept of CSRF, and the mitigations proposed (I found both Wikipedia CSRF entry and OWASP CSRF page good explanations). They generally introduce some state that the client needs to keep and present back to the server, so the server knows requests still come from the right client.
I am facing, though, that the client implementation becomes very "dirty" because of that and I was wondering if there could be cleaner solutions. Specifically, one that would not require handling additional state.
One solution I am thinking of, but wanted to check out with you, is to use some
Authorization header that is not
According to RFC 2617, section 2, regarding
Basic authentication scheme, the username and password may be cached by the browser and re-sent without asking to the user under certain conditions, and that's what it makes it vulnerable to CSRF:
A client SHOULD assume that all paths at or deeper than the depth of the last symbolic element in the path field of the Request-URI also are within the protection space specified by the Basic realm value of the current challenge. A client MAY preemptively send the corresponding Authorization header with requests for resources in that space without receipt of another challenge from the server.
I also verified that
Authorization: OAuth (used in OAuth 1.0 authenticated endpoints) and
Authorization: Bearer (used in OAuth 2.0 authenticated endpoints) are not automatically sent by the browser.
So, my question is: would you consider that an endpoint protected by OAuth/Bearer authorization headers should take additional precautions to prevent CSRF?