同源策略与跨站总览

前端里很多“权限被拦”“请求发了但拿不到”“Cookie 不带上”“iframe 不能访问父页面”的问题，本质上都和浏览器的同源策略、跨源访问和跨站限制有关。

什么是同源策略

同源策略是浏览器的一套安全限制，用来防止一个来源的页面随意读取另一个来源的敏感数据。

判断是否同源，主要看三项：

• 协议
• 主机
• 端口

三者都相同，才算同源。

https://app.example.com:443
https://app.example.com:443 // 同源
http://app.example.com:443 // 不同源
https://api.example.com:443 // 不同源
https://app.example.com:8443 // 不同源

同源策略主要限制什么

同源策略不是“什么都不让跨源”，而是重点限制读取敏感数据。

常见受限场景：

• AJAX / fetch 读取跨源响应
• 访问跨源 iframe 的 DOM
• 读取跨源窗口对象的大部分属性
• 某些存储能力不能跨源共享

什么叫跨站

跨站和跨源不是一回事。

• 跨源：看协议、主机、端口
• 跨站：更偏站点归属，通常看注册域名

app.example.com
api.example.com

它们通常不同源，但往往属于同站。

这也是为什么 Cookie、SameSite、第三方上下文问题，经常要用“跨站”而不是“跨源”去理解。

浏览器不是完全禁止跨源

浏览器允许很多“发送型”跨源行为，但会限制“读取型”能力。

例如：

• <img src="...">
• <script src="...">
• <link href="...">
• <iframe src="...">

这些资源通常都能跨源加载，但不代表当前页面就能随意读取对应内容。

和 CORS 的关系

CORS 是浏览器在同源策略基础上，为跨源 HTTP 读取增加的一套放行机制。

也就是说：

• 同源策略是默认限制
• CORS 是例外放行规则

如果跨源接口没有正确返回 CORS 响应头，浏览器就不会让前端脚本读取响应内容。

和 Cookie / SameSite 的关系

跨源请求要不要带 Cookie，不只受 CORS 影响，还要看：

• credentials
• SameSite
• Secure
• 第三方 Cookie 策略

所以“接口跨域 + 登录态失效”通常不是单一问题。

iframe 为什么常出问题

如果一个页面嵌入了跨源 iframe：

iframe.contentWindow.document

通常会直接被浏览器拦截，因为这相当于跨源读取另一个页面的 DOM。

如果确实需要通信，通常使用：

• postMessage

常见误区

“跨域就是后端问题”

不准确。跨域本质上是浏览器安全模型问题，后端只是配合声明允许哪些来源读取。

“能请求到就是没跨域”

不准确。请求可能已经发出，也已经收到响应，但浏览器仍然可能阻止前端读取结果。

“跨源和跨站是一个意思”

不是。它们关注的维度不同，尤其在 Cookie 和隐私策略中差别很大。

开发建议

• 先分清问题属于跨源读取，还是跨站携带凭证。
• 请求问题优先排查：同源策略、CORS、Cookie、SameSite、credentials。
• 页面间通信优先考虑 postMessage，不要试图直接跨源操作 DOM。
• 本地开发经常通过代理伪装成同源，线上部署后要重新审视真实来源关系。