網站的一切安全基礎就是「同源政策」。
網站的資源
網站資源：程式碼、圖片、影片…等。
同一個瀏覽器，可能開了兩個網站，但是兩個網站之間不會互相請求對方的資源，只會請求自己網站所需的資源。(可以打開 Chrome 的開發者工具來查看網站下載的網路資源，打開 Sources 左側選單都是下載下來的網路資源。Application 的左側選單可以看見 Cookie ，從伺服器端下載到客戶端，這也是網路資源的一部份。)
自己的網站資源只給自己人存取，不同體系的網站彼此不會互相請求資源，否則會造成安全性問題。
同源政策概念
同一體系又簡稱為「同源」，所以「同源」的資源才能互相存取。而跨來源的資源必須在特定狀況下才能允許存取。( 這樣的設計可以防範駭客攻擊 )
DOM 同源政策
對於 DOM 元素所定義的同源政策
符合條件：Scheme、Domain、Port，如果都相同就是 DOM 同源。( 不用管 Path )
找出與 http://abcde.com/admin/login.html DOM同源的網址1. http://abcde.com/contact/contact.html 同源
2. http://abcde.com/about.html 同源
3. http://abcde.com:81//admin/order.html 不同源， port 號不同
4. https://abcde.com/product.html 不同源，Scheme 不同
5. http://fg.abcde.com/order.html 不同源，Domain 不同
DOM 同源政策限定行為：
- 通常跨來源寫入被允許：從 HTML 發出的 HTTP Request，像是連結(links)、重新導向(redirect)、表單(form)送出等等，通常會被允許。如果是透過 JS 的 XMLHttpRequest 或是 Fetch API，就無法做跨來源寫入。
- 通常跨來源嵌入被允許：例如
<iframe>、<img>、<script>、<video>...。 - 通常跨來源讀取不被允許，例如透過 JS 的 XMLHttpRequest 或是 Fetch API。
DOM 同源政策對於 HTML 發出的跨來源寫入/嵌入/讀取較為寬鬆，駭客就會透過HTML 跨來源寫入/嵌入/讀取來破壞 (CSRF 攻擊)。對於 JS 發出的跨來源寫入/嵌入/讀取有限制。
Cookie 同源政策
限定 Cookie 資源回傳到伺服器端 (Server) 的規範。
Cookie 就像通行證一樣，用來做伺服器端(Server)與客戶端(Client)之間的溝通。
瀏覽器中存了這麼多 Cookie ，那要怎麼判斷 Cookie 是否同源 ？
符合條件：Domain、Path 相同就是 Cookie 同源，若 Server 有先將 Cookie 設定 Secure ，就要另外判斷 Scheme 是否為 https 才送出。 (不用管 Port)
----- JS 屬於 DOM 同源， Cookie 屬於 Cookie 同源。
那用 JS 存取 Cookie 時，要怎麼判斷資源存取的權限？
在母網域下使用document.cookie只會取到主網域自己的 cookie ，不會讀取子網域或是其他網站的 cookie。
在子網域下使用document.cookie也是只會取到子網域自己的 cookie ，不會讀取母網域或是其他網站的 cookie。
不過，在實務上，母網域與子網域通常會共用 Cookie。那要怎麼讓母、子網域共用 Cookie ？
設定就能共用，在伺服器端 Domain 網域最前面加上一個.就可以讓母、子網域共用 Cookie，但是做這個設定會影響 JS 存取 Cookie 的權限，會讓子網域的程式碼有辦法修改母網域的 Cookie，這對網站安全會有威脅，如果子網域被駭客攻陷，就能修改到母網域 Cookie。
例如：
母、子網域的 Cookie 不可以共用
Set-Cookie: name=value; domain=abcde.com
母、子網域的 Cookie 可以共用
Set-Cookie: name=value; domain=.abcde.com
限定行為
- 不同源的 Cookie ，傳輸時會送到各自來源的主機
- 母、子網域要共用 Cookie 需要經過設定
潛在的安全議題
- DOM 同源政策對於 HTML 發出的跨來源寫入/嵌入/讀取較為寬鬆，駭客就會透過HTML 跨來源寫入/嵌入/讀取來破壞 (CSRF 攻擊)
- DOM 同源政策沒有限制子網域去修改/覆蓋母網域的 Cookie
