I have an API to secure. There will potentially be two types of consumers of this API - our own Single Page Application, and third party services that will integrate with it.

I have read that in general cookies are not favoured for REST APIs, it is better to use header fields. Perhaps this is just convention.

Secure cookies are a better place to hold the auth token in an SPA. It prevents them from being obtained by a cross-site script attack. Also, if the SPA opens a new window/tab, the sessionStorage does not flow accross, causing the user to have to log in again. You can use localStorage, but not a good idea to keep auth tokens there, as it persists.

Should I make the authentication filter on the server side accept either a cookie or a header field? Try the cookie first, and if it is not there then try the header field? Cookies would be used by SPAs, and header fields by other API consumers. Or, would it be better to go with only one way of transmitting the auth token?

  • 3
    Clarification: the Secure cookie flag ensures the cookie is only transmitted over HTTPS (mitigates MITM); the HTTPOnly cookie flag ensures that JavaScript can't access the cookie value (mitigates XSS). Transmitting auth stuff in headers can mitigate CSRF. – PlasmaSauna Apr 8 '16 at 18:28
  • @PlasmaSauna Thanks for that. With cookies, something extra must be added to the requests to prevent CSRF, for example, a sequence number in a header field. – user2800708 Apr 11 '16 at 10:45
  • (Oh! Facepalm -- you mentioned both Secure and HTTPOnly in the title of your question. Yeah, you probably know what's up with those.) – PlasmaSauna Apr 12 '16 at 7:37
  • 1
    Cookies are transferred in HTTP header fields. So technically there is potentially very little distinction between the two. – a CVn Apr 12 '16 at 7:55
  • Yes, cookies are header fields. What they offer over header fields is that browsers use the 'httponly' and 'secure' flags to handle them in a more secure way. A little distinction, but an important one. – user2800708 Apr 12 '16 at 8:48

For the situation as you described, I recommend transmitting authentication information only in cookies. As you mentioned, this prevents the exfiltration of a user's authentication token from your Single-Page Application.

As an added bonus, having the authentication token as a cookie simplifies the logic in your authentication filter, since there's only one place to check.

Do note that if there is an XSS flaw in your SPA, attacker JavaScript can still issue requests impersonating the user whether you use cookies or headers for the authentication token. So, please, sanitize your output :-)

  • Why do so many APIs use header fields for the access token? Paypal, for example: developer.paypal.com/docs/api/auth-headers . I'm concerned that using cookies might be defying convention, even though it would seem to be better from a security view. – user2800708 Apr 12 '16 at 8:45
  • Is the answer that, since cookies do no prevent XSS, like you describe, they are not really more secure than using a header field? – user2800708 Apr 12 '16 at 8:52
  • 1
    Not quite. If the attacker steals the value of the authentication token, they can use it from their own computer(s) at a later date as long as the authentication token is still valid server-side. That's a good reason to prevent the theft of the authentication token. – PlasmaSauna Apr 13 '16 at 3:00
  • True, but you only make auth tokens valid for a short time. If an attacker can implicitly use the token with XSS attack, then they might as well use it straight away from their script. – user2800708 Apr 13 '16 at 9:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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