Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

Thanks!

share|improve this question
    
I can't work out what you're asking for. You struggle with passing a CSRF token around. Surely you still have to pass session information around with OAuth. (You specifically don't want the browser to handle it automatically). Also, XHR draft spec suggests (though I have not tested) you could set an Authorization: Basic header manually; the browser wouldn't cache that. –  sourcejedi Mar 13 '13 at 19:37
1  
Yes @sourcejedi I believe passing the OAuth token is less complex than a variable token that changes often. Also, most often those tokens are passed as GET/POST parameters, which makes the API dirtier. –  gimix Mar 14 '13 at 15:45
add comment

1 Answer

As long as you are not using Basic or cookie authentication for your API you do not need to worry about CSRF.

share|improve this answer
    
This is what I believe, however, how can I validate that assumption? Is there a specification for that? –  gimix Mar 14 '13 at 15:47
    
No spec that I know of states this explicitly, but OAuth 2.0 relies on this assumption, and it is used extensively. –  titanous Mar 14 '13 at 18:32
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.