我們都知道JavaScript可以操作web文檔的內容，試想，如果不對這一點加以限制，那么JS可以做的事情就太多了，危險性也太高，所以就針對它可以操作哪些文檔的內容有了一個限制，這個限制就是同源策略。
同源策略在什么情況下會起作用呢？當web頁面使用多個<iframe>元素或者打開其他瀏覽器窗口的時候，這一策略就會起作用。
同源策略的含義：腳本只能讀取和所屬文檔來源相同的窗口和文檔的屬性。
這里就涉及到了一個瀏覽器如何判斷兩者是否同源已經如何判斷腳本來源的問題。
注意一點：腳本本身的來源並不作為判斷是否同源的依據，而是將腳本所屬文檔的來源作為判斷依據。
1. 判斷腳本來源
例如：文檔A中通過script的src引用了一個外部腳本，這個腳本時google提供的，也是從google的主機上加載到文檔A中的，那么這個腳本的所屬文檔是誰呢，答案是文檔A。
2. 判斷是否同源
理解了腳本來源，接着理解怎么判斷是否同源：如果兩個文檔在
協議、主機以及載入文檔的URL端口這三點中有一點不同，就認為他們不同源。
同源策略固然在安全性上有了很大提高，但這種做法屬於“寧可錯殺三千，不可放過一個”。如果一個多域名站點需要在不同的子域之間共享屬性，同源策略就會變得很煩人了。以下介紹三種實現“不嚴格的同源策略”的方法：
1. 使用Document對象的domain屬性
默認情況下，屬性domain存放的是載入文檔的服務器的主機名。這一屬性是可寫的。
如果兩個窗口包含的腳本把domain設置為了相同的值，那么這兩個窗口就不再受同源策略的約束，它們就可以相互讀取對方的屬性。
2. 跨域資源共享（Cross-Origin Resource Sharing）
這種方法用新的“Origin：”請求頭和新的響應頭“Access-Control-Allow-Origin”來擴展HTTP。
3. 跨文檔消息（Cross-Document Messaging）
允許來自一個文檔的腳本可以傳遞文本消息到另一個文檔里的腳本，不管來源是否相同。
調用window對象的postMessage()方法，可以異步傳遞消息事件到窗口的文檔里。這種方法僅僅是一種消息傳遞技術。