为什么浏览器允许设置一些没有 CORS 的标头，但不允许设置其他标头？试图避免预检

Question

出于延迟性能原因，我试图避免0 CORS 对授权 GET 请求的预检请求。简单的方法是将访问令牌放入 URL 查询参数中，但这是一种糟糕的安全做法1。

根据这个答案2，浏览器的目标是阻止使用 HTML 标记（如 img 或 script）无法完成的任何事情。但如果是这样，为什么允许设置像Accept或Content-Langage这样的标题？您不能在 img 标签上设置它们。此外，是什么阻止我将访问令牌隐藏在 Accept 标头中，如下所示：

Accept: */*, x-access-token/<access_token>

在这种情况下，浏览器政策似乎没有增加额外的保护，并鼓励开发人员使用不安全的做法或讨厌的黑客行为。我错过了什么？

Answer 1

问题是什么？

仅供参考：您实际上没有可以回答的单一问题。你已经有一百万了。

您的标题提出了一个相当哲学的无法回答的问题，但您的帖子要求的是用例的解决方案。

为什么浏览器允许设置一些没有 CORS 的标头，但不允许设置其他标头？

个人/团队偏见。政治。宗教。

在这种情况下，浏览器政策似乎没有增加额外的保护，并鼓励开发人员使用不安全的做法或讨厌的黑客行为。我错过了什么？

它被称为“安全剧院”。

当了解更多的人做出的政治选择对于那些不具备理解这些事情（或不必实施）知识的人来说似乎很容易（或很难）理解接受它，这样他们就可以继续他们的生活——或者在威瑞信、VPN 和其他的情况下——以赚取利润。

为什么允许设置像 Accept 或 Content-Langage 这样的标头？

这些是良性标题，不携带任何特别可识别或敏感的内容

尽量避免使用访问令牌进行预飞行

执行此操作的简单方法是将访问令牌放入 URL 查询参数中，但这是一种糟糕的安全做法。

是和不是。

如果它是会话令牌并且持续 90 天...当然，有一些缺点...假设您没有使用 https（这很糟糕）或者攻击者已经 可以访问用户的机器（通过代码或其他方式）...在这种情况下，攻击者可以访问他们的电子邮件以重置他们的所有密码和登录名，可能还有他们的 MFA（即 iMessage / Authy / LastPass） ...嗯

如果它是非敏感数据（即社交媒体垃圾）上的短暂（“短”意思，比如 15 分钟）令牌，谁在乎？

您还可以制作一个一次性令牌，假设您不将敏感信息放入令牌本身，这会让每个人都开心。

肮脏的想法

您是否考虑过建立一个可以代理请求的端点？这就是现在所有孩子都在做的事情（看看你的 GraphQL）。

如果你足够努力，iframes 总是有一些方法可以被滥用来解决你的问题。它们是网络的 WD-40（或胶带）。 搜索你的感受......你知道这是真的。