浏览器为什么选择了如今的同源策略

[wheelg]

浏览器会禁止下面的类似操作

a.com中的 js 向b.com/api发送了请求，根据同源策略，这样的跨域请求会向b.com 发送一个 OPTIONS 预检请求，如果服务器返回的 Access-Allow-Origins 中不包含a.com ，那么此次请求会被浏览器拒绝，a.com中的 js 拿不到请求返回的数据。

这样的行为如果发生在本地应用程序例如 postman 中时，是可以拿到正常的请求数据的，因为 postman 没有同源策略，不会限制发送任何请求，那么为什么浏览器要对此做出限制？

网上的大部分解释是，浏览器在向某个域名发起请求时，会携带上对应的网站 cookie ，如果用户登录了b.com，又打开了a.com，a.com向b.com/api发送的请求会带上b.com的 cookie ，会让b.com服务器认为是用户本人在操作，导致恶意攻击的发生。

那么为什么浏览器不能分辨是哪个网站发起的请求呢？为什么浏览器不能在检测到是a.com发出的请求时，不携带b.com网站保存的 cookie 呢？这样不就能同样规避此类攻击吗？就如同在浏览器直接输入 api 网址那样拿到返回结果不行吗？

我的理解是，浏览器厂商不能这样做，因为许多广告厂商需要在网站中嵌入第三方 cookie ，这样才能通过第三方 cookie 来确定同一用户，方便广告投放，但是这个说法也显然站不住脚，因为如今许多浏览器厂商都在主动禁止第三方 cookie ，那么这个同源策略到底保护的是什么呢？

[3dwelcome]

@duke807 "我懷疑這麼設計主要目的是為了降低跨域引發的 DDoS 攻擊的烈度"

我们想到一块去了。

安全性是 CORS 之一，但是很多大网站安全性，比如网银转账 API ，铁定不会只依赖于 Access-Allow-Origins 设置，那样也太不靠谱了。

光看 GITHUB CORS 对 GET 限制，就是让后台 API 不会被其他网页随意调用。万一一个大网站被挂了恶意 JS ，用大量的 AJAX 占用 GITHUB 后台访问请求，那几乎就是 DDOS 了。

[cxe2v]

@duke807 #59 但是这样你也拿不到 github.com 的 cookie ，因为网页是向你自己的服务器发起的请求

[duke807]

@cxe2v 理論上 第三方 cors proxy 也可以中轉 cookie

[choury]

@duke807 浏览器又不会把 github.com 的 cookies 发给你的 proxy.zzz 的代理

[pppan]

SOP 的核心是防止信息泄露，和 cookie 关系不大。对于携带三方 cookie 发送跨站请求的 CSRF 攻击防护方法是使用 SameSite Cookie 、CSRF Token 等等。SOP 不能阻止你发送请求，因为很多接口是可以通过简单 GET/POST 触发的，`<img src="http://localhost/reboot">` 同样可以触发。但是 SOP 可以防止你收到请求的返回，通过 js 从跨站接口窃取用户数据。

[Al0rid4l]

@duke807 我从来就没有说过一定要用 cookie, 我只是针对楼主的问题作出回答, 请不要把这样的观点强加到我身上
而针对你说的, 你用 refer 也可以选择是否给予服务, 的确, 但这只是你 a.com 和 b.com 私下的协议, 浏览器并不知情, 确实如你所说你自己做好判断能够保证资源不被其他站点获取, 一方面这仅仅针对 http 请求, 另一方面这样私下的协议浏览器并不知情. 当然你可能会问为什么要浏览器知情? 如果每个开发运维人员都能够很好的做好安全措施, 那这个世界的确会美好很多, 但显然不是这样的, 依靠这些判断来保证安全增大了开发和运维的心智负担, 大部分人都做不好, 而浏览器作为 web 的入口, 他选择承担让 web 更安全这样的责任, 提供了这样的机制, 是有意义的
而回到这个帖子, 我不知道为什么这么多人把目光都放在 cookie token 这样的东西上, 同源策略不仅仅是针对这些东西的, 它限制的内容很多, 而 cookie 仅仅是其中之一而已.
事实上同源策略还限制了很多 js API, 包含了跨域写, 跨域读, 跨域嵌入资源几个方面, 而限制主要体现在跨域读这件事情上, 比如 a.com 引用了 b.com 的图片, 如果没有 cors 允许, 那 a.com 页面的 js 不能读取图片的二进制内容, 而图片的二进制内容可能泄漏敏感信息, 当然这个例子可能并不能感受到, 一个图片能泄漏什么敏感信息. 但同样的, 假如 a.com 用 iframe 嵌入了网银登录页面, a.com 的 js 能够读取嵌入页面的变量, hook 里面的函数, 那显然是有问题的. 当然你也可以用 X-Frame-Options 来防止 iframe 嵌入, 但是同样地, 如前面所说, 并不是每个人都知道使用这些来保证安全, 而浏览器替他们完成了这一保障总是好的

[Al0rid4l]

@pppan 这么多回复里就这个说到点子上了

[cyrbuzz]

浏览器目前的做法就是如你所说的，所以你的疑问并不存在= =，看 MDN:

`https://developer.mozilla.org/zh-CN/docs/Web/HTTP/CORS#%E9%99%84%E5%B8%A6%E8%BA%AB%E4%BB%BD%E5%87%AD%E8%AF%81%E7%9A%84%E8%AF%B7%E6%B1%82`

XMLHttpRequest 或 Fetch 与 CORS 的一个有趣的特性是，可以基于 HTTP cookies 和 HTTP 认证信息发送身份凭证。一般而言，对于跨源 XMLHttpRequest 或 Fetch 请求，浏览器 **不会** 发送身份凭证信息。如果要发送凭证信息，需要设置 XMLHttpRequest 的某个特殊标志位。


如果想要携带 cookies ，必须在发起请求时要求 XMLHttpRequest 或者 Fetch 携带 cookies ，并且服务器也需要允许`Access-Control-Allow-Credentials: true`，且附带 cookies 的情况下，其他跨域属性均不能为通配符，必须指定一个准确的值。

[ljpCN]

@wheelg #32 app 发布需要应用商店审核，网站只要你开放一个 http 端口就行，自然浏览器需要防范得比操作系统更多。

[aecra1]

没有同源策略钓鱼网站就能变成真网站。

[chnwillliu]

大家都不审题啊，楼主没说浏览器为什么要同源策略，楼主是说为什么浏览器不能一刀切死，每个网站一个沙箱，大家各自井水不犯河水。

同源策略就是一套带着枷锁跳舞的规则，一方面要给到开发者一定程度的自由，一方面还要保证安全性。

[HelloAmadeus]

@wheelg 我尽量解释清楚哈，steampowered.com 和 steamstatic.com 都是 steam 的 domain ，但是 steam.com 不是，假如不加入没有同源策略，steam.com 就可以攻击 steampowered.com 的用户，（添加 src 或者页面伪装一下）。假如同源策略严格到域名必须一致， 那么 steampowered.com 就无法和 steamstatic.com 共享 cookie ，这对网站维护方太麻烦了，不能为了安全一刀切。
至于 postman 发送是另外一回事了，当用户使用 postman 带 cookie 请求的时候，是用户主动行为，不属于黑客攻击了。举个例子，很多抢购工具都依赖 cookie 登录，需要用户把浏览器中登录 cookie 设置好然后用软件发送请求抢购，显然用户是知道这个行为的，和跨域攻击没有关系。
所以先了解跨域攻击，知道其边界在哪里，问题就自然而然明白了。这也是初入一个领域学习的要领，遇到问题先不要急于下手，而是先去准确定义问题，先去刨根。比如现在这个问题，为什么选择了如今同源策略？定义问题的过程中就会有，什么是同源策略？跨域攻击是什么？同源策略解决了跨域攻击中哪些问题？所以我才让你去了解跨域攻击。
希望能帮到你。