I have a Single Page Application which is fully HTML+JS+CSS (using frameworks such as jQuery and AngularJS) and a server side API using ASP.NET WebApi.

The SPA is served in a server similar to a CDN and also packaged using Cordova for use in smartphones.

The server side API has a lot of methods which needs authorization and authentication, hence I have to login and pass an identifier from the client side so the server would know who I am.

The problems I am facing:

  1. Once authenticated, where should I store the access token \ session ID?

    currently I have built my own authentication method (not OAuth) which returns a session ID, which the client puts in every subsequent HTTP calls in the Authorization header. However, when a user decides to refresh the page, the header is now gone. Solutions are to either save the session ID in a sessionStorage which might be insecure (OWASP doesn't recommend so, but perhaps X-Frame-Options = SAMEORIGIN would be suffice?) or use a HttpOnly cookie for the session management, which brings me to the next point:

  2. If I am using Cookies it's understood that I need to check for CSRF, but if i'm not? is there any reason to add a CSRF? it's in the same scope for the session ID.

  3. I have my own user system and group management which has a robust access checks. Is there any advantage for me to use OAuth and OpenID if I already have a working authorization filter which checks what I need, and isn't roles-string-based? (i.e. Roles="Administrators" etc., but fully CanChangeResource(x))

I have failed to find similar questions which may answer my problems and would appreciate an informative answer.

  • I am having trouble figuring out exactly what your question is. You seem to have a lot of little questions rolled into this. Is your question How can I securely manage sessions on a SPA that currently doesn't have CSRF protection? – Neil Smithline Jan 9 '16 at 18:41
  • I actually have a few small questions but the main one is where do I store the session token in the SPA app in such a way that with page refreshes it won't lose it? - because if it's in the sessionStorage, how do I secure it? and if it's in the HttpOnly Cookie - am I not breaking the idea of the RESTful api? and should I use CSRF in this case? – Albert Jan 9 '16 at 19:36

Looking at the two options you presented, sessionStorage or HttpOnly cookies, there is a trade-off. You are correct that if you use cookies, you need a CSRF token, and if you use sessionStorage and use that as the source for your header, you do not.

However, what OWASP is concerned about with sessionStorage, is that an XSS vulnerability allows an attack to extract authenticated sessions. With an HttpOnly cookie, it does not. Given the prevalence of XSS on the web today, this is a threat to consider seriously.

So, while sessionStorage would be the simpler option, and may well work with little modification to code you currently have in place, the HttpOnly cookie plus an anti-CSRF token would be the more secure approach. You have to decide if the extra effort is worth it to you, for your application.

  • Thank you very much! This has helped me have a better view on the issue. I will definitely check and test these options. – Albert Jan 9 '16 at 21:29
  • @Albert You could store the session ID in the httpOnly cookie and a secondary CSPRNG value attached to the session (server-generated) inside sessionStorage to act as a CSRF token. That way you have the best of both worlds. – Jonathan Gray Jan 10 '16 at 6:16

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.