我一直在阅读有关修复 CSRF 攻击的内容。通过一些研究，我了解到检查非标准标头可以防止 CSRF 攻击，因为浏览器不会自动发送此类标头。
所以我假设为我目前正在测试的 ASP 应用程序推荐使用Authorization: Bearer tokens。由于浏览器本身不会发送此标头值，因此我假设这种方法可以解决 CSRF 问题。但后来我注意到一个堆栈溢出问题，这让我有点困惑。答案仍然建议使用 CSRF 令牌。
所以，基本上我有两个问题。
这种方法真的可以防止 CSRF 攻击吗？
是的。攻击者无法让浏览器发送包含授权标头和正确不记名令牌的请求。这有两个原因：
但是，这可能对您的应用程序中的更改很敏感。例如，如果有一天有人决定将身份验证系统更改为基于 cookie 的东西，他们可能没有意识到他们这样做会禁用您的 CSRF 保护。
此外，在所需的标头值是可预测的情况下，允许设置该标头的 CORS 策略可能会带来麻烦。
至于链接的 SO 问题，我不确定我是否理解接受的答案。但是，如果您查看第二个答案，您的情况是类型#2，而不是类型#1。
我知道如果我容易受到 XSS 攻击，我的 cookie 可以被读取并且不记名令牌可以被盗。但是注入的 XSS 能否创建 Authorization: Bearer 标头并附加从 cookie 中窃取的值？
是的，如果你能注入代码，你就可以这样做。
如果您有 XSS 漏洞，它将允许攻击者绕过您设置的任何 CSRF 保护。因此，对 XSS 的担忧不能真正用于支持一种形式的 CSRF 保护而不是另一种形式 - 面对 XSS，它们都是无效的。
这里的一个细微差别是您的令牌不能标记为仅 HTTP，因为您需要从 JS 访问它以将其放入标头中。因此，XSS 攻击者可以窃取它，然后方便地从她自己的计算机发送请求。如果身份验证令牌是 HTTP-only，则攻击者必须让注入的代码发送请求，这有点麻烦但并非不可能。
它可以工作，但 XSS 会完全破坏会话。
CSRF 缓解的目的是限制谁可以将数据从用户浏览器提交到服务器并导致某些事情发生的范围。CSRF 攻击依赖于 Web 浏览器的特殊属性，因为它们通常在所有请求中都包含 cookie，攻击者只需要让浏览器向目标 URL 发送请求即可。您可以通过使请求包含不属于浏览器通常发送的请求的数据来缓解这种情况；例如，由 JavaScript 注入的自定义标题或表单字段。
Authorization 标头中的不记名令牌必须由 JavaScript 添加，因为浏览器永远不会包含它（除非 NTLM/Nego/etc，但这是另一个主题）。因此，这非常符合上述要求。
需要注意的是，在该页面上执行的任何 JavaScript 都可以执行与添加标头的代码完全相同的事情，因为这里没有安全边界。这意味着你被允许任意代码执行的任何形式的 XSS 所困扰。事实上，它使您处于较弱的位置，因为他们可以窃取您的令牌并在浏览器范围之外用它做任何他们想做的事情，而受保护的 cookie 不能被窃取，因为它不能被 JavaScript 访问。
所以......如果你能完全阻止 XSS，你是安全的，但在最好的情况下这是一项艰巨的任务。也就是说，在混合中添加 cookie 不一定有帮助，因为 XSS 可以生成添加令牌的请求，并且浏览器仍然会愉快地包含 cookie。