同源策略(Same-Origin Policy)与跨域安全机制详解
字数 1742 2025-11-25 05:23:24

同源策略(Same-Origin Policy)与跨域安全机制详解

1. 问题描述
同源策略(SOP)是浏览器最核心的安全基础,用于限制不同源的文档或脚本之间的交互。若缺少SOP,恶意网站可能通过脚本窃取用户在其他网站(如银行、邮箱)的敏感数据。但实际开发中,前端常需跨域访问资源(如API调用),因此需在安全与功能间平衡。本知识点将深入解析SOP的规则、跨域场景及安全机制(如CORS、JSONP等)。


2. 同源策略的定义与规则

  • 源(Origin)的组成:协议(Protocol)、域名(Domain)、端口(Port)三者完全一致即为同源。例如:
    • https://example.com/app1https://example.com/app2 同源(协议、域名、端口均相同)。
    • http://example.comhttps://example.com 不同源(协议不同)。
  • 受限操作
    • Cookie/LocalStorage 访问:仅同源页面可读写。
    • DOM 访问:iframe 内不同源页面无法通过脚本操作父页面DOM。
    • AJAX 请求:默认禁止跨域发送异步请求(但可发送请求,响应被浏览器拦截)。

3. 跨域需求的常见场景

  • 前端分离架构:前端部署在 https://frontend.com,需调用后端 API https://api.com
  • 第三方资源加载:使用公共CDN(如Google Fonts)或嵌入地图服务。
  • 单点登录(SSO):子域名间共享认证状态(如 sso.example.comapp.example.com)。

4. 跨域解决方案与安全机制

4.1 CORS(跨域资源共享)

  • 原理:服务器通过HTTP头声明允许的跨域来源、方法、头信息等,浏览器据此放行响应。
  • 简单请求与预检请求
    • 简单请求:方法为GET/POST/HEAD,且Content-Type为 application/x-www-form-urlencodedmultipart/form-datatext/plain。浏览器直接发送请求,服务器返回 Access-Control-Allow-Origin: https://frontend.com 即可。
    • 预检请求:非简单请求(如PUT、自定义头)时,浏览器先发送OPTIONS请求检查权限,服务器需响应 Access-Control-Allow-Methods: PUT 等头信息,通过后才发送实际请求。
  • 安全配置示例
    Access-Control-Allow-Origin: https://trusted-site.com  # 限制具体源,避免使用通配符*
    Access-Control-Allow-Credentials: true  # 允许携带Cookie时需指定具体源
    Access-Control-Expose-Headers: X-Custom-Header  # 允许前端访问的自定义头
    

4.2 JSONP(JSON with Padding)

  • 原理:利用 <script> 标签跨域加载资源,通过回调函数传递数据。
  • 风险:缺乏错误处理,且依赖第三方服务器安全性(若被篡改可能执行恶意代码)。
  • 示例
    <script src="https://api.com/data?callback=handleData"></script>
    <script>
      function handleData(data) { console.log(data); }
    </script>
    

4.3 其他跨域技术

  • postMessage API:安全地跨窗口通信,需验证消息来源避免恶意数据注入。
  • 代理服务器:前端请求同源代理,代理转发至目标域名(避免浏览器限制)。
  • 子域名跨域:设置 document.domain = "example.com" 实现子域名间协作(需协议端口一致)。

5. 安全防护要点

  • CORS配置陷阱
    • 避免 Access-Control-Allow-Origin: *Access-Control-Allow-Credentials: true 同时使用,否则可能导致凭证泄露。
    • 严格校验 Origin 头,防止伪造(如校验白名单)。
  • CSRF防护:跨域请求仍需防范CSRF(如添加Token验证),CORS不替代CSRF防护。
  • 内容安全策略(CSP):通过 Content-Security-Policy 头限制脚本来源,降低XSS与JSONP风险。

6. 总结
同源策略是Web安全的基石,而跨域机制是必要的灵活性补充。开发者需明确:

  • 跨域方案需遵循最小权限原则(如CORS严格限制源)。
  • 结合其他安全措施(如CSRF Token、CSP)形成纵深防御。
  • 定期审计第三方依赖的跨域行为,避免引入漏洞。
同源策略(Same-Origin Policy)与跨域安全机制详解 1. 问题描述 同源策略(SOP)是浏览器最核心的安全基础,用于限制不同源的文档或脚本之间的交互。若缺少SOP,恶意网站可能通过脚本窃取用户在其他网站(如银行、邮箱)的敏感数据。但实际开发中,前端常需跨域访问资源(如API调用),因此需在安全与功能间平衡。本知识点将深入解析SOP的规则、跨域场景及安全机制(如CORS、JSONP等)。 2. 同源策略的定义与规则 源(Origin)的组成 :协议(Protocol)、域名(Domain)、端口(Port)三者完全一致即为同源。例如: https://example.com/app1 与 https://example.com/app2 同源 (协议、域名、端口均相同)。 http://example.com 与 https://example.com 不同源 (协议不同)。 受限操作 : Cookie/LocalStorage 访问:仅同源页面可读写。 DOM 访问: iframe 内不同源页面无法通过脚本操作父页面DOM。 AJAX 请求:默认禁止跨域发送异步请求(但可发送请求,响应被浏览器拦截)。 3. 跨域需求的常见场景 前端分离架构:前端部署在 https://frontend.com ,需调用后端 API https://api.com 。 第三方资源加载:使用公共CDN(如Google Fonts)或嵌入地图服务。 单点登录(SSO):子域名间共享认证状态(如 sso.example.com 与 app.example.com )。 4. 跨域解决方案与安全机制 4.1 CORS(跨域资源共享) 原理 :服务器通过HTTP头声明允许的跨域来源、方法、头信息等,浏览器据此放行响应。 简单请求与预检请求 : 简单请求 :方法为GET/POST/HEAD,且Content-Type为 application/x-www-form-urlencoded 、 multipart/form-data 或 text/plain 。浏览器直接发送请求,服务器返回 Access-Control-Allow-Origin: https://frontend.com 即可。 预检请求 :非简单请求(如PUT、自定义头)时,浏览器先发送OPTIONS请求检查权限,服务器需响应 Access-Control-Allow-Methods: PUT 等头信息,通过后才发送实际请求。 安全配置示例 : 4.2 JSONP(JSON with Padding) 原理 :利用 <script> 标签跨域加载资源,通过回调函数传递数据。 风险 :缺乏错误处理,且依赖第三方服务器安全性(若被篡改可能执行恶意代码)。 示例 : 4.3 其他跨域技术 postMessage API :安全地跨窗口通信,需验证消息来源避免恶意数据注入。 代理服务器 :前端请求同源代理,代理转发至目标域名(避免浏览器限制)。 子域名跨域 :设置 document.domain = "example.com" 实现子域名间协作(需协议端口一致)。 5. 安全防护要点 CORS配置陷阱 : 避免 Access-Control-Allow-Origin: * 与 Access-Control-Allow-Credentials: true 同时使用,否则可能导致凭证泄露。 严格校验 Origin 头,防止伪造(如校验白名单)。 CSRF防护 :跨域请求仍需防范CSRF(如添加Token验证),CORS不替代CSRF防护。 内容安全策略(CSP) :通过 Content-Security-Policy 头限制脚本来源,降低XSS与JSONP风险。 6. 总结 同源策略是Web安全的基石,而跨域机制是必要的灵活性补充。开发者需明确: 跨域方案需遵循最小权限原则(如CORS严格限制源)。 结合其他安全措施(如CSRF Token、CSP)形成纵深防御。 定期审计第三方依赖的跨域行为,避免引入漏洞。