浏览器实现同源策略的方式是否存在实质性差异

Are there substantial differences in the way browsers implement the same-origin policy?

本文关键字：存在 是否 实质性 方式 实现 策略 浏览器      更新时间：2023-09-26

我的主页上有一个表单，设置为通过XHR POST提交到URL https://mydomain.com/send_sms。

当我在Internet Explorer（http://mydomain.com）中访问非SSL版本的主页并提交表单时，没有任何反应。在Webkit控制台中，我收到一个有用的错误，指出Origin http://mydomain.com is not allowed by Access-Control-Allow-Origin.

然而，在Firefox 13中，请求明确提交并返回200 OK，尽管响应正文为空。此外，服务器端操作（发送短信）实际上是由 Firefox 请求触发的，而不是由其他浏览器触发的。

我一直认为同源策略甚至拒绝发送请求，但也许是浏览器从响应中接收数据是不允许的？

有

谁知道这是否是Mozilla在实现（甚至可能是疏忽）方面的有目的的差异？

首先，http://example.com和https://example.com是不同的起源。对于 XHR 级别 1，这意味着不允许跨源请求。

但是对于当前的 XHR（级别 2），当支持 CORS 时（服务器和客户端都支持！），跨源请求可以是

  • 一个简单的跨组织请求，如果

    • 请求方法是GET、HEAD或POST，并且
      • 除了
    • Accept、Accept-Language、Content-Language 或 Content-Type 之外，没有其他请求标头字段是 ，并且
    • 未设置印前检查标志

    或

  • 否则需要预检的跨源请求。

对于简单的跨源请求，允许浏览器发送请求。但是当收到响应时，它需要检查服务器是否允许共享资源。这是检查Access-Control-Allow-Origin标头字段和其他Access-Control-*响应标头字段的位置。并且只有当此检查通过时，浏览器才允许脚本读取响应。

对于其他跨源请求，需要进行预检，以便与服务器协商允许在实际请求中发送哪些信息。此预检请求基本上是一个OPTIONS请求，告诉服务器实际请求将包含什么（请求方法和标头字段）。然后服务器可以决定是否允许此类请求。

在您的情况下，观察到的行为可能有多种原因。我想您的send_sms脚本只是不支持 CORS 的服务器端部分。

应该禁止发送数据，就像接收数据一样，例如，如果此页面上有一些恶意JS，并且它将每个击键提交到某个随机服务器怎么办？在这种情况下，发送比接收更邪恶（顺便说一句，这实际上可以通过请求带有查询字符串的图像或脚本等资源来实现，因为它们不受同一源策略的约束）。

我过去遇到过细微的差异，但这通常是旧版IE的。

对我来说，Firefox 差异是一个错误（提供原版安装具有此特征）。不同的协议（HTTP vs HTTPS）等同于不同的来源，即使是同一协议上的子域也被认为是不同的来源，所以FF13绝对不应该发出AJAX请求。

您没有设置CORS（跨源资源共享），并且FF13是您测试过的唯一支持它的浏览器吗？

相关文章：