El principal argumento para el almacenamiento local parece ser este:
es más fácil protegerse contra XSS que proteger contra XSRF
El argumento para eso es que XSS se soluciona supuestamente mediante el saneamiento automático de entradas, mientras que CSRF es difícil de entender.
El segundo punto puede o no ser cierto, pero, como lo indica su fuente, la protección completa contra CSRF es relativamente simple. Si su aplicación es tranquila, es simplemente una cuestión de verificar todas las solicitudes POST para un token CSRF *.
XSS por otro lado no es tan simple. El saneamiento de entrada no es la solución, la codificación de la salida es. Y el problema es que esta codificación depende del contexto. Por ejemplo, se necesita una codificación diferente si se encuentra en un contexto de JavaScript o HTML.
Mientras que algunos marcos proporcionan motores de plantillas con codificación automática, otros no. Y la codificación automática generalmente solo codifica HTML, pero no considera XSS en un contexto de JavaScript. Además de que muchos desarrolladores omiten los motores de plantillas en algunos casos y envían directamente las entradas de los usuarios, diría que XSS es más difícil de defender que CSRF.
* Esto está un poco simplificado, y hay otras cosas que considerar. La inyección de HTML, por ejemplo, puede perder tokens CSRF, y la aplicación puede usar solicitudes GET para cambiar el estado del servidor.
Conclusión
No estaría de acuerdo en que XSS es más fácil de defender que CSRF. Como este es el principal argumento para el almacenamiento local, me gustaría utilizar el enfoque de cookies. Proporciona una pequeña mitigación para XSS y también tiene el beneficio adicional de garantizar que los datos relevantes solo se envíen a través de HTTPS (a través del atributo de cookie segura).