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 Basic
.
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?