CROS 同源问题的一些疑问

@unco020511 是的，你这个第二点说的很对，用户凭证这个东西不是标准，每个网站实现都不一样，所以我才对这个 MDN 里面关于用户凭证对 Access-Control- 各种头部的限制和要求不太理解。 有点疑惑。

简单请求没有跨域的问题吧

@chinafengzhao

那你继续想想为什么会要有预检请求呢？ 你已经接近理解了：
https://github.com/amandakelake/blog/issues/62

（随收一搜）

假设跨域情景下的三个角色：用户（以及使用的浏览器），用户访问的网站 A ，网站 A 请求的网站 B 。
首先要明确，跨域规则究竟是在防谁，是为了解决什么问题？
用户访问网站 A ，或者用户访问网站 B ，网站与自身的互动都是同源的，被浏览器信任。
用户访问网站 A 时与网站 B 产生互动，用户可能并不知道会涉及网站 B ，网站 B 也不能信任来自其它前端的不可靠输入，这样的互动是浏览器所要阻止的。
所以，跨域规则是在防当前访问的网站 A 的恶意操作，保护用户与网站 B 之间的数据安全。
如果网站 B 允许网站 A 的跨域请求，那么实际上跨域保护的作用已经结束了。

再来看第一个问题，
> “我做为可能有恶意脚本的黑客……我的恶意 js……”
这里假定了网站 B 是恶意方，用户访问的网站 A 是正常的，但如果网站 A 都已经请求了恶意 js ，那网站 A 还是清白的吗？
OP 在 20L 举了一个 CDN 投毒攻击的例子，但你首先要想到，在 CDN 投毒之前，这一切是正常运作的，网站 A 请求了网站 B 的资源，网站 B 允许网站 A 的跨域请求。
后来其中某一方背叛了信任，虽然是不同源，但这根本不是跨域规则所要解决的问题，也就是需要禁止的跨域资源访问（非法请求访问合法资源），这直接就相当于是注入代码了。

第二个问题，
> “它咋知道我的请求带不带身份呢”
你没写过附带身份凭证的前端请求？你不明确附带身份凭证，那浏览器就不会发送附带身份凭证的请求。凭证是由浏览器管理的，你无法在前端代码中修改跨域请求附带的凭证 https://fetch.spec.whatwg.org/#forbidden-request-header
> “这个服务端必须是为什么要必须明确呢？如果不明确会怎么样呢？ ”
同样地，在跨域的语境下，你要搞清楚哪方是攻击方，哪方是受保护方（响应端、用户是被保护方，请求端是潜在的攻击方）。
不明确就说明后端根本没有考虑到可能有来自不明源的攻击，既然不遵循浏览器的安全规则，浏览器就当你是需要被保护的对象，禁止一切风险行为。

我不得不说，很多人理解就错了。CORS 出发点不是“为了安全”，而是为了灵活。

很多人说的其实是 SOP ，同源策略。说白了就是分隔不同站点的 cookie ，认证 header ，资源等。
而后又发现其实有时候我们也是需要跨域访问的，比如你前后段分离。但是因为 SOP ，很多事情都做不了。

所以要打一个补丁，但是你总不能破坏 SOP 吧？所以搞了这一堆机制。存在部分安全限制的灵活。
很多人的困惑就是因为直接看了 CORS ，就觉得这莫名其妙。所以楼主你还是从 SOP 看起吧。


而且人们普遍对 web 攻击理解是有问题的。

比如 3 楼，说的“跨站脚本攻击”，实际上就错了。你说的更像是 CSRF 。
你要是说跨站脚本攻击，但是它的发起可以是同源的，这种 CORS 防不了。
你描述的 CSRF 有时候根本不需要响应内容。服务器收到就好。这种 CORS 也防不了。


而后楼主在 20 楼的问题，这是 CSP 可以解决的。你可以在 html 里给调用的 js 直接写上 hash ，浏览器会自动验证 hash 。可以应对投毒。


如果你在乎安全，去看看 CSP ？

@UnluckyNinja > 在跨域的语境下，你要搞清楚哪方是攻击方，哪方是受保护方（响应端、用户是被保护方，请求端是潜在的攻击方）。 这句话很经典，受教了