Skip to content

同源策略

同源策略(Same-Origin Policy, SOP)是浏览器中一个关键的安全机制,旨在防止不同来源的网页脚本之间进行恶意交互。它限制了来自不同源的“写”操作,并严格控制了“读”取其他源的数据的能力。这一策略对于保护用户隐私和防止跨站脚本攻击(XSS)至关重要。

什么是“源”

在讨论同源策略时,“源”由三个部分组成:协议(如 http 或 https)、域名(如 example.com)以及端口号(如果指定了的话)。只有当两个 URL 在这三个方面完全相同时,它们才被认为是同源的。例如:

  • http://example.com/page1.htmlhttp://example.com/page2.html 是同源的。
  • http://example.com/page1.htmlhttps://example.com/page1.html 不是同源的,因为协议不同。
  • http://example.com:8080/page1.htmlhttp://example.com/page1.html 不是同源的,因为端口号不同。
  • http://sub.example.com/page1.htmlhttp://example.com/page1.html 不是同源的,因为子域不同。

同源策略的应用

  1. DOM 访问:同源策略限制了一个源加载的文档或脚本如何与另一个源的资源进行交互。例如,JavaScript 不能直接读取非同源页面的内容。

  2. XMLHttpRequest 和 Fetch API:这些用于发起 HTTP 请求的 API 默认情况下只能向同源的服务器发送请求。尝试向非同源地址发送请求将会失败,除非目标服务器明确允许跨域请求(通过 CORS 机制)。

  3. Cookie、LocalStorage 和 IndexedDB:这些存储机制也受到同源策略的保护。每个源都有自己的独立存储空间,无法从另一个源直接访问这些数据。

跨源资源共享 (CORS)

为了克服同源策略带来的限制,特别是允许合法的跨域请求,W3C 引入了 CORS 标准。通过设置适当的 HTTP 头部,服务器可以告诉浏览器哪些外部域有权访问其资源。

  • 简单请求:某些类型的 GET、POST 或 HEAD 请求被视为“简单请求”,只要服务器响应包含适当的Access-Control-Allow-Origin头部,就可以成功执行。

  • 预检请求(Preflight Request):对于那些不被认为是简单的请求(比如使用自定义 HTTP 方法或设置特定的头部),浏览器首先会发出一个 OPTIONS 请求来询问服务器是否允许该请求。只有在收到肯定的回答后,才会实际发送原始请求。

  • 凭据支持:如果需要在跨域请求中包含凭证(如 Cookies 或 HTTP 认证信息),则必须设置Access-Control-Allow-Credentials头部为 true,并且Access-Control-Allow-Origin不能使用通配符(*)。

总之,同源策略是浏览器安全模型的重要组成部分,它有效地阻止了许多潜在的安全威胁。然而,随着 Web 应用变得越来越复杂,合理地配置和利用 CORS 变得尤为重要,以便既能保证安全性又能满足现代 Web 应用的需求。

CORS 标准与同源策略区别

CORS(跨源资源共享,Cross-Origin Resource Sharing)和同源策略(Same-Origin Policy, SOP)都是与 Web 安全相关的概念,但它们的作用和实现方式有所不同。理解这两者的区别有助于更好地保护 Web 应用的安全性并满足现代 Web 开发的需求。

同源策略 (SOP)

定义:

  • 同源策略是浏览器实施的一项关键安全措施,旨在防止不同来源的网页脚本之间进行恶意交互。
  • 它规定了一个源加载的文档或脚本如何与其他源的资源进行交互。简单来说,它限制了来自不同源的“写”操作,并严格控制了“读”取其他源的数据的能力。

作用范围:

  • DOM 访问:JavaScript 不能直接读取非同源页面的内容。
  • XMLHttpRequest 和 Fetch API:默认情况下只能向同源服务器发送请求。
  • Cookie、LocalStorage 和 IndexedDB:每个源都有独立的存储空间,无法从另一个源直接访问这些数据。

特点:

  • 通过协议、域名和端口号来定义“源”。只有当这三个要素完全相同时,才被认为是同源。
  • 主要目的是防止恶意网站读取另一个网站的数据,从而保护用户隐私和安全。

CORS(跨源资源共享)

定义:

  • CORS 是一种机制,它使用额外的 HTTP 头部让浏览器和服务器能够确定是否允许跨域请求。它提供了一种方法来放松同源策略的限制,允许在特定条件下从一个域访问另一个域的资源。
  • CORS 是由服务器配置的,通过设置适当的 HTTP 响应头告知浏览器哪些外部域有权访问其资源。

工作原理:

  • 简单请求:如果请求符合某些条件(如 GET、POST 方法,Content-Type 为text/plain, multipart/form-data, 或者 application/x-www-form-urlencoded),则可以直接发送请求,无需预检。
  • 预检请求(Preflight Request):对于不符合简单请求条件的请求(例如 PUT 方法或自定义头部),浏览器首先会发出一个 OPTIONS 请求到目标服务器,询问服务器是否允许实际请求。只有得到肯定答复后,才会真正发起请求。
  • 凭据支持:如果需要在跨域请求中包含凭证(如 Cookies 或 HTTP 认证信息),必须设置Access-Control-Allow-Credentials头部为 true,并且Access-Control-Allow-Origin不能使用通配符(*)。

作用范围:

  • 允许合法的跨域请求,同时保持一定的安全性。
  • 适用于 XMLHttpRequest、Fetch API 等异步请求场景。

区别

  1. 目的不同

    • 同源策略:主要目的是保护用户免受潜在的安全威胁,如跨站脚本攻击(XSS),通过限制不同源之间的交互来达到这一目标。
    • CORS:提供了一种可控的方式放松同源策略的限制,使得不同的 Web 应用可以安全地共享资源。
  2. 实现方式不同

    • 同源策略:由浏览器强制执行,无需任何服务器端配置。
    • CORS:需要服务器通过设置特定的 HTTP 响应头来明确允许哪些源可以访问资源。
  3. 灵活性

    • 同源策略:非常严格,不允许跨源读取数据。
    • CORS:提供了灵活的配置选项,可以根据需求精确控制谁可以访问资源以及如何访问。

总结来说,同源策略是一种内置的安全措施,用于阻止不同来源的网页之间不必要的交互;而 CORS 则是在此基础上提供的一种解决方案,允许在满足一定条件的情况下进行跨源请求,既增强了功能又不失安全性。正确理解和应用这两者对于构建高效且安全的 Web 应用至关重要。

Released under the MIT License.