如何判斷網站的 same-origin/cross-origin，same-site/cross-site，SameSite 與 cookie 的再探討

本站的主題是商業，創業，美食，葡萄酒，閱讀，網路科技。

這是我的 FB粉專以及 IG，我比較常使用 Threads，歡迎大家追蹤互動~

https://web.dev/same-site-same-origin/
偶然看到 web dev 的一篇好文，整理了一遍 same-origin/cross-origin, same-site/cross-site 中間的不同。首先 origin 的概念，可以參考我之前的文章網站的跨源資源共享 Cross-Origin Resource Sharing (CORS)

“目前網路協定走的是 Same-origin policy，兩個網頁 scheme, hostname, port 都相同，就算 same-origin，彼此可以存取資源 (例如圖片、CSS、JS)。”

再來看 same-site。首先我們要知道，網址有一個 Top-level domain (TLD)，.com, .tw 都算 TLD，所有的 TLD 定義在 Root Zone Database。但是後來又有問題，.co.jp, .github.io 這些不算 TLD 阿，但實際網址會使用這些後綴，所以後來又出了一個 effective TLD (eTLD)。.co.jp, .github.io 這些就是屬於 eTLD。

eTLD+1 指的則是網址的 TLD，和 TLD 前的部分。例如 my-project.github.io，eTLD 是 github.io，eTLD+1 則是 my-project.github.io。

只要 eTLD+1 相同的兩個網頁就算 same-site，不用管 scheme 同不同，不用管 port 同不同，不用管 sub-domain 同不同，只要 eTLD+1 相同就算 same-site。

https://web.dev/schemeful-samesite/
後來為了更好的安全性，尤其 same-site 的判斷跟 cookie 是否能發送有關，又出了一個 schemeful same-site。其中 scheme 會納入考量，即使網址完全相同，HTTP / HTTPS 視為 cross-site。

但必須提醒讀者，schemeful same-site 還算是新東西 (目前是 2021 年 8 月)，每種瀏覽器，每個瀏覽器版本行為可能不同。但大趨勢應該是往這方向走。

上方連結有特別舉例，http://site.example, https://site.example 兩站互相站外連結。兩站本來算 same-site，SameSite=Strict cookie 可被送回。但如果用 schemeful same-site 規則，兩站算 corss-site，SameSite=Strict cookie 不會被送回。但因為是簡單站外連結，SameSite=Lax cookie 仍可以送回。

如果 http://site.example 中嵌入 https://site.example 的圖片。兩站本來算 same-site，SameSite=Strict cookie 可被送回。但如果用 schemeful same-site 規則，兩站算 corss-site，SameSite=Strict cookie 不會被送回。SameSite=Lax 嵌入資源的情況，cookie 也不會被送回。

SameSite=Strict, Lax, None;Secure 行為上的不同，請參考之前的文章 Chrome 80 開始更新 SameSite 規則，預設禁止存取第三方 cookie

要知道一個 request 到底屬於哪一種，檢查它的 HTTP header Sec-Fetch-Site。它有四種值：1) cross-site, 2) same-site, 3) same-origin, 4) none

文件有說 Sec-Fetch-Site 不包含 schemeful same-site，所以 Sec-Fetch-Site 的 same-site 應該是不看 scheme 的。再來，因為 same-origin 的條件是 scheme, hostname, port 都要相同，比 same-site 還嚴謹，所以如果是 same-origin 的話資源、cookie 傳輸都沒問題。