我在努力避免0 CORS出于延迟性能的考虑，对授权的GET请求进行预检。简单的方法是将访问令牌放在URL查询参数中，但这是一种不好的安全做法。1.
根据这个答案2浏览器的目标是阻止任何不能用HTML标签实现的东西，如 img 或 script. 但如果是这样的话，为什么允许设置头像 Accept 或 Content-Langage? 你不能把这些设置在 img 标签。另外，是什么阻止了我将我的访问令牌隐藏在 Accept 这样的头。
Accept: */*, x-access-token/<access_token>
似乎浏览器的政策在这种情况下 并没有增加额外的保护， 并鼓励开发人员使用 不安全的做法或讨厌的黑客。我错过了什么？
提示：其实你并没有一个单一的问题可以回答。你有，好像，一百万个问题。
你的标题提出了一个相当哲学性的无法回答的问题，但你的帖子是在询问一个用例的解决方案。
为什么浏览器允许设置一些没有CORS的头文件，而不允许设置其他的头文件？
个人团队的偏见。政治。宗教信仰。
在这种情况下，似乎浏览器的政策并没有增加额外的保护，并鼓励开发人员使用不安全的做法或讨厌的黑客。我错过了什么？
这就是所谓的 "安全剧场"。
这就是当那些更了解的人做出一个看起来很容易（或很难）理解的政治选择时，那些没有知识理解这种事情（或不必实施它们）的人只是接受它，这样他们就可以继续他们的生活 - 或者在Verisign，VPN和其他人的情况下 - 赚取利润。
为什么允许设置Accept或Content-Langage这样的头文件？
这些都是良性的头信息，不携带任何特别可识别或敏感的内容。
简单的方法是将访问令牌放在URL查询参数中，但这是一种不好的安全做法。
是的，也不是。
如果是会话令牌，而且它能持续90天......当然，有一些缺点......假设你没有使用https（这是很糟糕的），或者攻击者 已经 有权访问用户的机器（通过代码或其他方式）......在这种情况下，攻击者可以访问他们的电子邮件，以重置他们所有的密码和登录，很可能还有他们的MFA（即iMessage Authy LastPass），所以......呵。
如果它是一个非敏感数据（即社交媒体垃圾）上的短命（"短 "的意思，比如15分钟）令牌，谁会在乎呢？
你也可以做一个 一次性 token，如果你不把敏感信息放在token本身，会让大家都很高兴。
你有没有考虑过建立一个可以代理请求的单一端点？这就是现在所有的孩子们都在做的事情（看着你GraphQL）。
而且如果你足够努力的话。iframes 总有一些方法可以被滥用来解决你的问题。他们是网络上的WD-40（或胶带）。搜搜你的感觉，你就知道是真的。