摘要：浏览器同源策略什么是浏览器同源策略同源策略是浏览器安全的基础。同源策略限制从一个源加载的文档或脚本如何与来自另一个源的资源进行交互。这里我们做一下简要的总结受到浏览器同源策略的限制，页面的无法被页面的访问和操作。不受同源策略的限制。

“同源策略”（Same Origin Policy）是浏览器安全的基础。

同源策略限制从一个源加载的文档或脚本如何与来自另一个源的资源进行交互。这是一个用于隔离潜在恶意文件的关键的安全机制。

在判断两个页面的url是否具有相同的源之前，我们先来看一下一个url（统一资源定位符）的基本组成部分。

对于一个url，它的基本组成部分是：协议 :// 域名（或者是ip） : 端口（如果指定了） / 路径。

那么下面我们来举个例子：

对于http://www.example.com/static来说，协议就是http，它的域名是www.example.com，它的路径是static，这里的端口号省略了（默认为80）。

值得一提的是，在这个域名下面，example.com是主域名，而www.example.com是子域名，同样的a.example.com也是一个与前面所述不同的另一个子域名。并且，上面这三个域名互不相同。

这里不再展开赘述，相关知识请查阅与计算机网络有关的知识。

那如何判断页面是否具有相同的源呢？

如果协议，端口（如果指定了）和域名对于两个页面是相同的，则两个页面具有相同的源。

也就是说，判断同源的三要素是：协议、端口、域名。

需要注意的是，如果是一个域名二级域名，比如上面提到的www.example.com，它与另外一个二级域名a.example.com，虽然他们的主域相同，但是子域不同，于是这两个就不是同一个域名，所以也不能说是同源。三级域名依次类推...

下表给出了相对http://store.company.com/dir/page.html同源检测的示例：

说到同源策略，必不可少的就是Cookie这个东西了。

而讲到Cookie，跟它关联在一起的又有Session。

对于这两者，这里不做大篇幅的介绍，具体去传送门查阅。

这里我们做一下简要的总结：

Cookie受到浏览器同源策略的限制，A页面的Cookie无法被B页面的Cookie访问和操作。

Cookie最大存储容量一般为4KB，由服务器生成，在HTTP报文首部设置Set-Cookie可以指定生成Cookie的内容和生命周期，如果由浏览器生成则在关掉浏览器后失效。

Cookie存储在浏览器端，由于每次发送HTTP请求默认会把Cookie附到HTTP首部上去，所以Cookie主要用来身份认证，而不用来存储其他信息，防止HTTP报文过大。

Session存储在服务器，主要与Cookie配合使用完成身份认证和状态保持的功能。只有Cookie或只有Session都无法完成身份认证和状态保持的功能。

最后，对Cookie和Session实现的身份认证和状态保持功能做一个举例。

假设现在有一个学生信息管理系统，此时数据库已经有学生的相关信息。（账号、密码、个人信息等等）
然后当学生登录这个系统，通过POST请求把用户的账户密码发送到后台服务器。当后台服务器接收到这些参数的时候，会跟数据库保存的记录进行匹配。
一旦匹配成功，也就是用户的账号密码都正确的情况下，这个时候后台服务器会在Session中记录一个值，可以是用户名或者其他能够唯一标识用户的字段。
当把这个值保存在Session中后，后台服务器会返回响应告知客户端登录成功，可以进行后续的操作。此时，后台服务器会在HTTP响应报文中添加一个字段Set-Cookie，它的值是当前Session的SessionID，（这个SessionID是指向我们当前的那个Session的，在Node的Express中express-session会封装好这个过程）当然还会设置Cookie的其他属性，比如说过期时间Expires等等。
当浏览器接收到这个HTTP响应报文的时候，就会在本地设置一个Cookie，它的过期时间由响应报文中Set-Cookie中的Expires字段的值决定，如果为空，则关闭浏览器（即会话结束时）后失效。
之后，每次向后台服务器发送请求的时候，浏览器默认会把这个Cookie加在HTTP请求报文的Cookie中。这样，每次后台服务器接收到请求的时候，会根据Cookie中的SessionID去找到我们的Session。
假如这个SessionID映射得到Session，那么这个时候说明浏览器是已经登录过了。于是，就可以进行后续的一些相关的操作。
另外，值得一提的是，Session机制决定了当前客户只会获取到自己的Session，而不会获取到别人的Session。各客户的Session也彼此独立，互不可见。也就是说，当多个客户端执行程序时，服务器会保存多个客户端的Session。获取Session的时候也不需要声明获取谁的Session。

这就是Cookie和Session做状态保持和身份验证的一个具体的例子。

说到同源限制，还有一个不得不提的就是iframe。

iframe可以在父页面中嵌入一个子页面，在日常开发中一旦使用，避免不了的就要涉及到不同的iframe页面进行通信的问题，可能是获得其他iframe的DOM，或者是获取其他iframe上的全局变量或方法等等。

同源下的iframe，也就是iframe中的src属性的URL符合同源的条件，那么通过iframe的contentDocument和contentWindow获取其他iframe的DOM或者全局变量、方法都是很简单的事情。

那如果是非同源的两个iframe，单纯的通过变量访问的方式就受到同源限制了。

为了解决这个问题，HTML5引入了一个新的API：postMessage，主要就是用来解决存在跨域问题的iframe页面之间通信的问题。

下面简单的举一个例子，假如现在有两个不同的页面，A页面的url是http://localhost:4002/parent.html，B页面的url的是http://localhost:4003/child.html，现在我把B页面用iframe嵌在A页面下面，代码（精简）是这样子的。现在我要实现的是向子页面B传递一个消息：

A页面代码：

    
A页面
    
    

B页面代码：

    
B页面
    

结果如图：

postMessage接受两个参数，一个是要传送的data，另外一个是目标窗口的源，如果想传给任何窗口，可以设置成*。
目标页面接收信息的时候，使用的是window.addEventListener("message", function() {})。

当然也有不受同源限制的情况存在，主要有以下列举的：

script标签允许跨域嵌入脚本，稍后介绍的JSONP就是利用这个“漏洞”来实现。

img标签、link标签、@font-face不受跨域影响。

video和audio嵌入的资源。

iframe载入的任何资源。（不是iframe之间的通信）