3 ms·
My concern with a Web Storage based token is additional latency. With this system, a page has to be served, javascript executed, and an XHR sent before an authe
by advisedwang 10y ago
My concern with a Web Storage based token is additional latency. With this system, a page has to be served, javascript executed, and an XHR sent before an authenticated response can be sent. With Cookies, the very weakness the author points out - sending it on the first HTTP resonse - is a massive asset for reducing latency.
Is there a way to mitigate this?
- avolcano 10y agoI think you could allow cookies only for the initial request (you may even be able to simply only allow cookies for GET requests, as long as you're careful to ensure your GET endpoints don't have data-manipulating side effects) and require passed tokens for all other kinds of requests. For example, you could use a cookie to authenticate serving GET /user/account-settings to render an HTML form, but then require submitting the form (e.g. POST /user/account-settings) to pass a token from localStorage. This wouldn't protect you from all kinds of cookie-based attacks, but at least you'd have a guarantee your endpoints aren't vulnerable to CSRFs.
- albinowax_ 10y agoThis approach is more suited to single-page apps, where the first request only fetches a template and all the subsequent requests to the website are done via AJAX. In the post I'm not really arguing that nobody should ever use cookies - just that Web Storage is an alternative with comparable security.