当某个互联网运营商的网站上规模之后，他们都会考虑将网站部署到主域名相同，子域名不同的服务器集群上，以此来构建一个聚合的应用。
同时，希望能够利用 JavaScript，在不同子域的网页间相互操作，实现一个对用户来说“无缝”的应用。这时，跨域操作的技术难点，仿佛一下子从服务器后台，转移到了浏览器前台。因为，浏览器将承载跨子域访问的任务。为什么会这么说呢？因为，我们已经步入了集成化的 RIA 时代。
一般情况下，通过运用 DOM 对象模型，不同窗口和框架里的内容可以通过JavaScript 互相作用。
但是，由于浏览器可以同时在窗口或框架中显示不同的页面，甚至是不同域下的页面。为了保证数据的完整性和信息的安全性，就必须建立起一种强制规则，来保证跨域的数据不会被非法的获取和修改。
多数情况下，只有相同域下的页面才能相互作用。比如，一个位于 域下的页面，可以自由地通过 JavaScript 读写 域下的其它页面，但却不能读写 home.microsoft.com 域下的页面，或是 域下的页面。完全的跨域访问（比如， 域下的页面访问 域下的页面），在 JavaScript 开发中是被完全禁止的，没有任何商量的余地。但是，DOM 为 document 对象提供了一个 domain 属性，可以授权“同主域但不同子域”页面间的数据访问，这正好可以应付那些“集团军”式的前台部署。
跨子域设置的规则：当两个二级域名，URL 协议，端口都相同的网页，自身都通过 JavaScript 显示地设置了相同的 document.domain 值，并且此值至少等于自身的二级域名，它们之间才可以相互作用。（注意，此规则只适用大于二级域名的页面，并且千万别指望 http 页面可以与 https 页面相互作用。）
也就是说，当网页作者指定 document.domain 属性为域名的后半部分时，读写许可将扩展至二级域名。例如： 下的某个页面，将 document.domain 属性设置成 microsoft.com，同时 下的某个页面，也将 document.domain 属性设置成 microsoft.com，它们之间即可完成跨子域的访问。因为，只有以 microsoft.com 结尾的站点上的文档，才可能将其 document.domain 属性设置为 microsoft.com，这样就确保了同一个服务提供者的页面，才能互相提供权限，从而完成交互操作。
注意，document.domain 属性值不能比二级域名更短（比如“com”，浏览器将禁止这种设置，并认为此操作是无效的）。但是，对于如 这样的域名，实际的最大操作权限应该是二级域名 microsoft.co.jp（而不是一级域名“co.jp”，浏览器不会像限制“com”那样，将“co.jp”认为是无效的。但如果你真这样做了，带来的风险可想而知）。
在窗口、对话框、框架（frameset，frame，iframe），甚至是 IE 的 popup 窗口之间（通过 IE 特有的 window.createPopup 方法创建），只要它们涉及到了相互读写，都要考虑 document.domain 问题。这仿佛是“一损俱损，一荣俱荣”的事情，一旦你在某个地方设置了 document.domain，你必须小心应对。因为，你不知道在哪个角落里，会出现“没有权限”的脚本错误。
让窗口或框架在不同域页面之间跳转，是件很寻常的事情，所以跳转操作总是被允许的。只有试图读写页面内容时，才会受到 domain 限制。例如：window.location 可以用来设置地址间的跳转，但是不能用它来读取在不同域下的地址。因为，这会使一个页面知道浏览者去过哪些地方，而这会暴露浏览者的隐私。
在不同域间的页面制约包括
window.location 可以设置，但不能读取。其它的 location 属性和方法被禁止访问；
document.href 可以设置，但不能读取。其它的 document 属性和方法被禁止访问；
<iframe> 的 src 可以设置，但不能读取；
浏览器为什么要加入跨域限制？
浏览器的跨域网页限制，是出于安全角度考虑的，为什么会这么说呢？请想像一下，如果没有域之间的安全限制，一个无赖网页可以“偷窥”别人浏览的页面，然后通过 Ajax 方式，将“偷窥”后的数据发送到某台不为人知的服务器上，它便实现了无耻的侵略行为。
再或者，这个无赖网页可以通过 DHTML 来更改别人页面的内容。比如：编写一个监视脚本，把用户已经打开的所有页面改换背景色，版权文字，以及放入一些自制的 banner，这样就可以把别人的整个站点变成“自己的”了。