想到一个很基础的前端面试题 ,诸君不妨一看

显然是 A 啊

显然 A 是可以决定向谁发起请求的，因此他的安全是自行控制的。但是 B 是被请求方，他不清楚运行环境如何。

单纯跨域没有任何意义，想打你随便写脚本就打死你，非浏览器不遵守跨域要求，这个保护的是 cookies 不被滥用吧

服务器是 B 那 cookies 也是 B 显然保护的是 B 的 cookies 不被滥用啊

确实是个好问题，2 年开发一脸懵逼，这个问题之前想过但从来没有考证过，于是刚查了一下。
把网页 A 想象成一个可以调用 B API 并且自动携带 B cookie 的应用程序，就可以理解了。防止未被 B 授权的 A 管理 B 的数据。

@imldy 这个以前是有现实例子的，最早浏览器 cookies 可以跨域，各家接口也没有一次性 token 验证，我只要在网页里构造一些 URL ，就可以让访问者关注一些人的微博，甚至在特殊帖子或者微博下回复

同源策略主要目的是保护用户在 A 站点的身份凭证不被其他站点滥用，服务器 B 的资源安全应该由服务器 B 自己来保障。

保护 B,因为你就在 A,想干嘛干嘛

应该是 B 吧，这个过程 A 是主动行为，B 是被动的

保护使用浏览器的用户不被 A 站欺骗（访问了 A ，但是在不知情的情况下被 A 站调取了用户在 B 的数据）

反推一下：当 B 告诉浏览器 A 站点的的访问是合法的时候。A 才能成功访问 B 。所以是保护 B 。

B 吧

请求不是重点吧，重点是跨域读不到 cookie

A 嵌入 B 时, 需要 A 的允许才能加载 B , 还是需要 B 的允许才能保护 B?

需要谁允许就是在保护谁.

这个问题有点陷阱
不知道楼主是不是故意的，在模糊 A 网站和使用 A 网站的用户。

同源策略主要是为了保护 B 网站的数据和资源安全，防止用户在访问 A 网站时被诱导对 B 网站进行未授权操作。

这是典型的 CSRF 攻击。

核心是 B ，请求 B 的时候，B 决定是否允许你跨过来操作，只有在指定了 cors 的域名才进行处理。

但是，很多企业或者研发乱配置，比如 options 请求的 allow origin 无脑返回*，或者直接将 options 请求转发到业务上，业务不判断 method 直接当正常请求处理（我今天还在跟跨部门后台掰扯这个，options 请求带了一次性的 token 过去被消费了，真正 post 的时候就返回 token 无效

这里要证明 A 网站和 B 服务器是达成一致的，所以保护的是 B 。我认为这个面试题不太好，有脑筋急转弯嫌疑。因为如果存在攻击场景，那 A 就是攻击者了，和大家平时开发中处理跨域问题时的场景不一样。

A 是主动的 B 是被动的，所以说是保护 B