_除非您可以防御XSS，否则请放弃所有希望！ _

_Abandon all hope unless you can secure against XSS! _

或

根据其他条件选择适合您的方法，因为两者都同样安全，同样不安全.

如果您使用cookie，则绝对应该使用double-submit-cookie防御或类似的方法，因为它在没有XSS的情况下确实可以保护您免受CSRF的侵害.也就是说，如果您不这样做，那么您肯定会受到来自其他域的CSRF攻击，甚至不需要XSS漏洞就能发挥作用.

If you use cookies, you should definitely use the double-submit-cookie defence, or something similar, because it does protect you against CSRF in the absence of XSS. That is, if you don't do this, you're definitely open to CSRF attacks - from other domains - that don't even require XSS exploits to work.

但是，无论哪种方式，您的源代码都是公开可用的(在您的浏览器中为JavaScript)，因此对于有动机的黑客而言，在查找要从本地存储中提取的令牌与读取XSRF-TOKEN Cookie的工作量之间没有显着差异.如果Evil Corp可以在您的域中运行某些JavaScript(即XSS)，那么您将无所适从.

But either way, your source code is publicly available (JavaScript in your browser) so for a motivated hacker, there is no significant difference in effort between finding which token to pull from local storage and reading your XSRF-TOKEN cookie. If Evil Corp can get some JavaScript running in your domain - that's XSS - then you're hosed.

• Cookie很方便，因为您不必编写JavaScript代码即可管理令牌-只需XSRF.

• Cookies are convenient because you don't have to write JavaScript code to manage the token - only the XSRF.

如果您想使用重定向，重定向也会变得更加自动化.

Redirection becomes a little more automatic too, if you want to use it.

本地存储更易于适应非浏览器应用程序-从服务器的角度来看，因为如果您说的是Java中不想处理cookie的Android应用程序，则服务器不会这样做.不需要在in和浏览器之间进行区分，因为它不使用cookie.

Local storage is easier to adapt to non-browser apps - from the server perspective that is, because if you write say, an Android app in Java that doesn't want to deal with cookies, your server doesn't need to make any distinction between in and the browser, since it's not using cookies.

无论如何，请下定决心，但要小心编写 和使用的第三方JavaScript的JavaScript！

Anyway, make up your own mind, but be careful about the JavaScript you write and the 3rd party JavaScript you use!