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?

  • 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, 2013 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, 2013 at 15:45

1 Answer 1


As long as you are not using using a built-in browser authentication scheme like Basic (or client certificates, digest, NTLM in some browsers, etc) or cookie authentication for your API you do not need to worry about CSRF.

  • 3
    This is what I believe, however, how can I validate that assumption? Is there a specification for that?
    – gimix
    Mar 14, 2013 at 15:47
  • 3
    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, 2013 at 18:32
  • 4
    Digest authentication, ntlm, negotiate and certificate auth are vulnerable to crsf and these aren't basic or cookie so it is wrong to say that. Just a note for others that may stumble across this answer, but if you could edit it that would be great. Nov 4, 2017 at 12:39
  • Note, that restricting redirect url on authorization server is wise, due to referrer header thing. tools.ietf.org/id/draft-ietf-oauth-security-topics-06.html
    – Lubo
    Mar 23, 2020 at 7:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .