概念:同源策略是客户端脚本（尤其是Javascript）的重要的安全度量标准。它最早出自Netscape Navigator2.0，其目的是防止某个文档或脚本从多个不同源装载。
这里的同源指的是：同协议，同域名和同端口。
精髓：
它的精髓很简单：它认为自任何站点装载的信赖内容是不安全的。当被浏览器半信半疑的脚本运行在沙箱时，它们应该只被允许访问来自同一站点的资源，而不是那些来自其它站点可能怀有恶意的资源。
为什么要有同源限制？
我们举例说明：比如一个黑客程序，他利用IFrame把真正的银行登录页面嵌到他的页面上，当你使用真实的用户名，密码登录时，他的页面就可以通过Javascript读取到你的表单中input中的内容，这样用户名，密码就轻松到手了。
Ajax应用：
在Ajax应用中这种安全限制被突破。
在普通的Javascript应用中，我们可以修改Frame的href，或者IFrame的src，以实现GET方式的跨域提交，但是却不能访问跨域的Frame/IFrame中的内容。
而Ajax它通过XMLHTTP进行异步交互，这个对象同样能够与远程的服务器进行信息交互，而且更加危险的是，XMLHTTP是一个纯粹的Javascript对象，这样的交互过程，是在后台进行的，不被用户察觉。因此，XMLHTTP实际上已经突破了原有的Javascript的安全限制。
如果我们又想利用XMLHTTP的无刷新异步交互能力，又不愿意公然突破Javascript的安全策略，可以选择的方案就是给XMLHTTP加上严格的同源限制。这样的安全策略，很类似于Applet的安全策略。IFrame的限制还仅仅是不能访问跨域HTMLDOM中的数据，而XMLHTTP则根本上限制了跨域请求的提交。
浏览器支持:而IE其实给这个安全策略开了两个想当然的后门，一个是：他假设你的本地文件，自然清楚将会访问什么内容，所以任何你的本地文件访问外部数据， 都不会收到任何的警告。另一个是：当你访问的网站脚本打算访问跨域的信息时， 他居然仅仅是弹出一个对话框来提醒你一下。如果一个欺诈网站，采用这样的手段，提供一个假页面给你，然后通过XMLHTTP帮你远程登录真实的银行服务器。只要10个用户里，有一个用户糊涂一下，点了一个确定。他们的盗取帐号行为，就成功了！ 你想想看，这是何等危险的事情！
FireFox就不是这样的做法，缺省的情况下，FireFox根本就不支持跨域的XMLHTTP请求，根本就不给黑客这样的机会。
避免同源策略：
JSON和动态脚本标记
<script type="text/javascript"
src="http://travel.com/findItinerary?username=sachiko&
reservationNum=1234&output=json&callback=showItinerary" />
当 JavaScript 代码动态地插入 <script> 标记时，浏览器会访问 src 属性中的 URL。这样会导致将查询字符串中的信息发送给服务器。在 清单 1中，所传递的是 username 和 reservation 作为名称值对传递。此外，查询字符串还包含向服务器请求的输出格式和回调函数的名称（即 showItinerary）。<script> 标记加载后，会执行回调函数，并通过回调函数的参数把从服务返回的信息传递给该回调函数。
Ajax代理
Ajax 代理是一种应用级代理服务器，用于调解 Web 浏览器和服务器之间的 HTTP 请求和响应。Ajax 代理允许 Web 浏览器绕过同源策略，这样便可以使用 XMLHttpRequest 访问第三方服务器。要实现这种绕过，有如下两种方法可供选择：
客户端 Web 应用程序知道第三方 URL 并将该 URL 作为 HTTP 请求中的一个请求参数传递给 Ajax 代理。然后，代理将请求转发给 [url]www.remoteservice.com[/url]。注意，可以把代理服务器的使用隐藏在 Web应用程序开发人员所使用的 Ajax 库的实现中。对于 Web 应用程序开发人员而言，它看上去可能完全不具有同源策略。
客户端 Web 应用程序不知道第三方 URL，并且尝试通过 HTTP 访问 Ajax 代理服务器上的资源。通过一个预定义的编码规则，Ajax 代理将 所请求的 URL 转换为第三方服务器的 URL 并代表客户检索内容。这样一来，Web 应用程序开发人员看上去就像是在和代理服务器直接进行通信。
Greasemonkey
Greasemonkey 是一个 Firefox 扩展，它允许用户动态地对 Web 页面的样式和内容进行修改。Greasemonkey 用户可以把用户脚本（user script）文件与一个 URL 集合建立关联。当浏览器通过该 URL 集合加载页面时，便会执行这些脚本。Greasemonkey 为用户脚本的 API 提供了额外的许可（与运行在浏览器沙盒中的脚本的许可相比较）。
GM_XMLHttpRequest 是其中的一个 API，它从本质上说就是一个不具有同源策略的 XMLHttpRequest。用户脚本可以将浏览的内置 XMLHttpRequest 替代为 GM_XMLHttpRequest，从而许可 XMLHttpRequest 执行跨域访问。
GM_XMLHttpRequest 的使用只能通过用户同意的途径才能受到保护。也就是说，Greasemonkey 只有在建立新用户脚本与特定 URL 的集合之间的关联时才会要求用户配置。然而，不难想象一些用户可能会被欺骗，在没有完全理解其后果时就接受该安装。
一.什么是同源策略
同源策略，它是由Netscape提出的一个著名的安全策略，现在所有的可支持javascript的浏览器都会使用这个策略。
为什么需要同源策略，这里举个例子：
假设现在没有同源策略，会发生什么事情呢？大家知道，JavaScript可以做很多东西，比如：读取/修改网页中某个值。恩，你现在打开了浏览器，在一 个tab窗口中打开了银行网站，在另外一个tab窗口中打开了一个恶意网站，而那个恶意网站挂了一个的专门修改银行信息的JavaScript，当你访问 这个恶意网站并且执行它JavaScript时，你的银行页面就会被这个JavaScript修改，后果会非常严重！而同源策略就为了防止这种事情发生.
比如说，浏览器的两个tab页中分别打开了http://www.baidu.com/index.html和http: //www.google.com/index.html，其中，JavaScript1和JavaScript3是属于百度的脚本，而 JavaScript2是属于谷歌的脚本，当浏览器的tab1要运行一个脚本时，便会进行同源检查，只有和www.baidu.com同源的脚本才能被执 行，所谓同源，就是指域名、协议、端口相同。所以，tab1只能执行JavaScript1和JavaScript3脚本，而JavaScript2不能 执行，从而防止其他网页对本网页的非法篡改。
二.Selenium Server为什么以这种代理服务器的形式存在
上面说了同源策略，那同源策略的Selenium Server有什么关系呢？？呵呵，上一篇说过，Selenium Core是一堆JS函数的集合，它是我们操作浏览器的基础。当存在同源策略时，便出现一些问题.
因为Selenium Core的JS脚本的“源”是localhost，所以浏览器会阻止Selenium Core的JS脚本在测试页面上执行，这就是为什么在本系列第一篇中说，如果只使用Selenium Core进行测试，需要把Selenium Core安装到远程服务器上。
为了解决上面这个问题，Selenium RC中的Selenium Server就以代理服务器的形式出现了.
Selenium Server以代理的形式存在，通过修改WebSite的源信息，从而达到欺骗浏览器的目的，就这样，Selenium RC就轻松绕过了同源策略。在上图中，浏览器会认为WebSite和Selenium Core来自同一个“源”----代理服务器！