La principale ragione di sicurezza per evitare i cookie sarebbe quella di prevenire attacchi CSRF , che è un obiettivo valido. I cookie non erano ben pensati da un punto di vista della sicurezza. D'altra parte, ci sono approcci consolidati per evitando CSRF, quindi non è una tecnica estremamente preziosa.
Dal punto di vista della privacy, i cookie (in particolare i cookie di terze parti) sono pericolosi. Per questo motivo, alcuni utenti e / o browser li bloccano, il che può fornire agli sviluppatori un motivo funzionale per usare qualcos'altro.
Tuttavia, anche per un'applicazione a pagina singola (SPA), probabilmente si desidera mantenere il token di sessione. Il metodo standard per eseguire questa operazione da JS consiste nell'utilizzare la memoria locale (archiviazione permanente o di sessione), che è fondamentalmente un modo per archiviare le variabili JS per un determinato sito attraverso visite utente o almeno carichi di pagina all'interno di una determinata sessione. Tutti i browser moderni supportano l'archiviazione locale.
Il principale svantaggio della sicurezza dell'archiviazione locale (o qualsiasi altro modo di fare la gestione programmatica delle sessioni sul client, invece di fare affidamento sul comportamento automatico dei cookie), è che un utente malintenzionato che ottiene XSS (Cross-Site Scripting) all'interno del tuo l'app web può rubare il token e dirottare la sessione per impersonare la vittima, anche dopo che la vittima chiude il browser (al contrario, il tipico cookie di sessione è contrassegnato come httponly , che impedisce a JS di leggerlo e limita il sequestro di sessione solo come a condizione che la vittima lasci aperta l'app Web.