越学越懵，同源策略到底是为了保护浏览器还是服务器？

是为了保护用户

你访问钓鱼网站时，同源策略限制网站无法在后台偷偷调用支付宝转账接口把你的钱转走

@mxT52CRuqR6o5 那 CORS 跨域是否会让同源破防？

@James369 能具体描述一下你所说的的”同源破防”吗？

@James369 这不叫破防，这叫授权跨域

那如果恶意攻击的服务器都返回 Access-Control-Allow-Origin：*，那启不是对浏览器很危险？

大哥，如果是培训班的多写几个项目。如果才进入职场，问问周围同事。浏览器请求服务端，服务端再响应浏览器，不是哪个服务器来请求浏览器。（ websocket 不提，websocket 也是浏览器主动建立连接）

好奇是好事，好奇就去看文档，Google 查。

首先，浏览器和服务器都没有价值，保护用户才有意义。
考虑两个经典场景
1.用户打开钓鱼网站：钓鱼网站尝试向源站点发起请求，因此一方面需要浏览器主动拒绝 response （同源策略），同时需要服务端防御 CSRF 攻击。
2.用户打开正经网站：部分数据被污染，因此需要防御 XSS 攻击

@James369
浏览器会默认限制跨域的访问（只有简单请求不会被跨域策略限制），如果确实需要跨域访问，则需要被访问的网站显式的在 response 返回 Access-Control-Allow-XXX 的 header 显式的声明允许谁跨域访问允许怎样的跨域访问
因此服务器无脑返回 Access-Control-Allow-Origin：*确实是很危险的行为
（当然上古时代还有个 jsonp 的跨域方案，现在似乎都不推荐了）

个人理解：首先同源策略是用来保护用户，方式跨站伪造请求和 xss 的，既不是保护浏览器也不是保护服务器。其次，Access-Control-Allow-Origin：*，等于服务器放弃限制，对于一些安全要求不高的无所谓的。

同源策略是用来保护客户端的。

先了解三个基本原理：
1. 浏览器会根据请求的域来记录 Cookies，当发出请求的时候，同样会携带与请求的域对应的 Cookies ；
2. 用户登录会话信息通常记录在 Cookies 中；
3. 每个网页都有一个主要的 Document 对象，而浏览器会将当前页面的域记录在 Document 对象的一个描述当前域的属性中。

假设没有同源策略：
1. 用户在网银网站登录，登录会话存储在网银网站域对应的 Cookie 里；
2. 用户访问钓鱼网站，钓鱼网站直接在浏览器端请求网银接口进行转账，浏览器自动读取了网银网站域的 Cookie，随请求一同发到网银服务器。
3. 网银服务器收到了请求，验证 Cookies 有效，即进行了转账操作。

假设网银接口服务器正确配置了 CORS 头信息，而浏览器的同源策略也能正常工作的话，第 2 步就会变成：
用户访问钓鱼网站，钓鱼网站尝试令浏览器请求网银接口进行转账，浏览器会先向网银网站的服务器询问 CORS 头，得知仅允许网银网站域请求，读取当前网页域为非网银网站域，则拒绝发出请求到网银服务器。

当然 WebStorage 也是按域存储和访问的，只不过不会自动随请求发送而已，会限制同一域的网页才能访问 WebStorage 的内容。

这套机制的有效性，建立在如下基础上的：
1. 用户用的浏览器是正规的、严格按照同源策略标准开发的；
2. DNS 没有被劫持，或开启了 TLS 验证，即不可能伪造相同的域；
3. 接口服务器正确配置了 CORS 头。
以上三项任意一项有问题都会使得同源策略失效。

当然 Web 安全是一套体系，同源策略只是其中一个机制，用于防范某几个安全风险，就像一个拼图，虽然防不了所有的攻击手段，但所有拼图都拼全了就能有完整的防御性了。

@libook 看完你这么一说，我突然有种提壶灌顶的感觉，也就是说服务方 为了确保用户是从自己的网页发起的正当请求（才给放行），其它地方过来的非法请求都可以用 Access-Control-Allow-Origin 来进行屏蔽。 （刚开始我还以为是服务器为了防止第三方盗链或者盗用接口而做的设定）。
那么，也可以想像为什么那么多国内厂商争先恐后的去做浏览器，这个浏览器的权限真是太大太重要了，简直就是一个操作系统。

现在网银转账都需要手机验证码了。还会校验 ip 是否是常用的 ip 地址。