Security 安全性-如果没有XSS预防，CSRF预防无效？

我正在AWS上开发一个无服务器应用程序，并使用Svelte.js和Sapper开发一个静态前端。对于用户管理，我使用AWS Cognito用户池。Cognito在执行auth操作时返回JWT令牌，因此这自然会导致在客户端将这些令牌存储在何处的问题

我已经了解了使用localStorage与Cookie的各种优缺点，以及第一个选项如何打开XSS漏洞，而第二个选项如何打开CSRF漏洞。我知道恶意脚本很容易访问localStorage，在那里存储JWT之类的敏感信息是有风险的。我也明白，使用http只能阻止javascript访问cookie，因此它们应该更容易受到XSS攻击

但是，在阅读文章时，我发现了一个有趣的说法：

但是，任何跨站点脚本漏洞都可以用来挫败目前市场上所有可用的CSRF缓解技术（除了涉及用户交互的缓解技术以及本备忘单后面所述的缓解技术）。。。必须确保不存在XSS漏洞，以确保无法规避CSRF防御

然而，同一指南中的另一项声明指出：

请注意，令牌本身可以缓解CSRF

这让我很困惑。是哪一个？用户交互之外的所有CSRF预防技术是否都易受攻击，或者基于令牌的技术是否可以接受

如果它们无效，而且由于CSRF预防依赖于XSS预防，这难道不意味着将JWT存储在Cookie中比将它们存储在localStorage中提供的安全性要差得多吗？如果我的应用程序中存在XSS漏洞，这不意味着我设置的任何CSRF防御实际上都是无用的吗

如果是这样的话，那么当我已经需要首先预防XSS时，为什么还要经历处理cookie和CSRF预防的麻烦呢

有人能帮忙解释一下这个问题吗？有没有一种方法可以正确地使用JWTs，而不使其暴露于XSS攻击？基于令牌的技术（如同步器模式或加密模式）真的有效吗

---

谢谢。

我也在尝试了解Sapper应用程序的最佳安全实践。我在这里找到了一些关于使用标题的内容：

更一般地说：

CSRF更全面的分类：

通过盖茨比的讨论，这里链接了一些更高级的概念：