Securing Single Page Apps and REST Services
jamesward.com
Securing Single Page Apps and REST Services
1–4 of 4 posts
Re: Securing Single Page Apps and REST Services
#2I'm not the author, I'm just curious what people think of this approach. Does it sound reasonable?
Re: Securing Single Page Apps and REST Services
#3I'm not the author, I'm just curious what people think of this approach. Does it sound reasonable?
This appears to be another mechanism to mitigate CSRF vulnerabilities, tailored to a single page app. It is quite similar to, for example, putting a security token into a form that is validated on post. The difference is that it is put into a header. This is probably less secure, in fact, because the token comes straight from the cookie. CSRF tokens are typically generated server side and can thus be made cryptographically strong.
It's funny because the author initially advocates against using cookies because they are susceptible to CSRF attacks, and then immediately suggests using cookies as part of this new scheme (albeit in a different way).
This is a good example of why you shouldn't design your own security system unless you are an expert in security and/or cryptography.
Re: Securing Single Page Apps and REST Services
#4I'm not the author, I'm just curious what people think of this approach. Does it sound reasonable?
This appears to be another mechanism to mitigate CSRF vulnerabilities, tailored to a single page app. It is quite similar to, for example, putting a security token into a form that is validated on post. The difference is that it is put into a header. This is probably less secure, in fact, because the token comes straight from the cookie. CSRF tokens are typically generated server side and can thus be made cryptograph…
I believe the scheme is still generating the token server-side, no?
"The server validates the login information and creates an authentication token for the user"