This question already has an answer here:

I am building the API for a SPA and Chrome plugin using Rails, and I am inclined to go use Secure HTTPOnly cookies for authentication because:

  • This is the default solution for standard Rails auth libraries like Devise and Sorcery.
  • Rails has encrypted client-side sessions, which means no server-side storage requirement or DB lookup (yes I know I will still need some kind of server-side tracking and lookup if I want to implement proper session invalidation).
  • It's transparent to web-based client libraries.
  • Cookies are somewhat hardened compared to local storage, and the problem space is well-trodden and understood.

When you enable Rails API mode it disables both cookies and CSRF protection, so I've re-enabled cookies, but CSRF protection is not as easy to re-enable because it assumes a form will be rendered first (ie. not a POST request coming in cold) and will probably require some fiddling to set up.

If cookies are disabled then I understand CSRF is a non-issue, however as far as I can tell, there is no way for a malicious site to forge a request for type application/json without using XHR, which would not be allowed without explicit CORS authorization.

Is it a sound security model to authenticate a JSON API with cookies but no CSRF token assuming proper content type validation?

marked as duplicate by Steffen Ullrich, Tobi Nary, Steve, Xander, RoraΖ Aug 28 '17 at 14:21

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 5
    In short: your assumptions are correct, i.e. if you enforce a specific content-type (or some other HTTP header) which can only be set by XHR and you don't explicitly allow cross-origin requests using a CORS policy then you are safe against CSRF. But, this is actually a duplicate of Are RESTful sites safe against CSRF attacks? and also CSRF and JSON APIs. – Steffen Ullrich Aug 26 '17 at 7:02
  • Thanks for those links, while they do answer the question, I don't think they emphasize that cookies are the CSRF vector. So this meme that RESTful APIs are safe from CSRF could be based on the expectation that an API to be cookie-less or it could be based on content type validation. Rails makes it very easy to throw the baby out with the bathwater here, so I think the explicit details of my question are useful. – gtd Aug 26 '17 at 17:55
  • Yes, these answers expect you to already know how a CSRF works and therefore the role of cookies for a CSRF. I had the assumption that you understand this too so there is no need to emphasize this again. – Steffen Ullrich Aug 26 '17 at 18:13

Yes, if you validate the Content-Type of the POST request, this can't be forged by an attacker in an XHR situation. Additionally, since you mentioned a Chrome "plugin" (extension?) it's worth noting that Chrome extensions maintain a separate cookie bucket, so a CSRF attack would require that an attacker manages to get your extension to issue a request on their behalf, not just a CSRF attacker in the main browser session.

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