L'argomento principale per la memorizzazione locale sembra essere questo:
it is easier to protect against XSS than protecting against XSRF
L'argomento per questo è che l'XSS è presumibilmente risolto con l'igienizzazione automatica degli input, mentre CSRF è difficile da capire.
Il secondo punto può o non può essere vero, ma - come afferma la tua fonte - la protezione completa contro CSRF è relativamente semplice. Se la tua applicazione è tranquilla, si tratta semplicemente di controllare tutte le richieste POST per un token CSRF *.
XSS d'altra parte non è così semplice. La sanificazione degli input non è la soluzione, codifica dell'output. E il problema è che questa codifica dipende dal contesto. Ad esempio, è necessaria una codifica diversa se ci si trova in un contesto JavaScript o HTML.
Mentre alcuni framework forniscono motori di template con codifica automatica, altri no. E la codifica automatica generalmente codifica solo HTML, ma non considera XSS in un contesto JavaScript. Aggiungendo a questo che molti sviluppatori saltano i motori dei template in alcuni casi e producono direttamente input dell'utente, direi che l'XSS è più difficile da difendere rispetto a CSRF.
* Questo è un po 'semplificato, e ci sono altre cose da considerare. L'iniezione HTML, ad esempio, può perdere i token CSRF e l'applicazione potrebbe effettivamente utilizzare le richieste GET per modificare lo stato del server.
Conclusione
Non sarei d'accordo sul fatto che l'XSS sia più facile da difendere rispetto a CSRF. Poiché questo è l'argomento principale per l'archiviazione locale, sceglierei l'approccio cookie. Fornisce una piccola attenuazione per XSS e ha anche il vantaggio di garantire che i dati rilevanti vengano inviati solo tramite HTTPS (tramite l'attributo cookie sicuro).