配置的同網站

「同網站」的定義正在演變，將納入網址架構，因此網站 HTTP 和 HTTPS 版本之間的連結現在會計為跨網站要求。預設升級為 HTTPS，盡可能避免問題，或繼續閱讀，瞭解需要哪些 SameSite 屬性值。

Steven Bingler

Rowan Merewood

含結構定義的同網站 會將「網站」的定義從可註冊網域，修改為結構定義 + 可註冊網域。如需更多詳細資料和範例，請參閱「瞭解『同網站』和『同源』」。

好消息是，如果網站已全面升級為 HTTPS，您就不必擔心任何問題。對你來說不會有任何影響。

如果尚未全面升級網站，請優先處理這項作業。 不過，如果網站訪客會在 HTTP 和 HTTPS 之間切換，本文稍後會說明一些常見情況和相關的 SameSiteCookie 行為。

您可以在 Chrome 和 Firefox 中啟用這些變更，進行測試。

• 從 Chrome 86 開始，請啟用 about://flags/#schemeful-same-site。在 Chrome 狀態頁面追蹤進度。
• 從 Firefox 79 開始，請透過 about:config 將 network.cookie.sameSite.schemeful 設為 true。使用 Bugzilla 問題追蹤進度。

將 Cookie 的預設值變更為 SameSite=Lax 的主要原因之一，是為了防範跨網站要求偽造 (CSRF)。不過，不安全的 HTTP 流量仍可能讓網路攻擊者有機可乘，竄改 Cookie，然後在網站的安全 HTTPS 版本中使用。在架構之間建立這個額外的跨網站界線，可進一步防範這類攻擊。

常見的跨架構情境

導覽

先前在網站的跨結構定義版本之間導覽 (例如從 http://site.example 連結至 https://site.example)，會允許傳送 SameSite=Strict Cookie。現在系統會將這類要求視為跨網站導覽，因此會封鎖 SameSite=Strict Cookie。

正在載入子資源

請注意，您在此處所做的任何變更都只是暫時的解決方法，最終還是要升級為完整 HTTPS。

子資源的例子包括圖片、iframe，以及使用 XHR 或 Fetch 提出的網路要求。

先前在網頁上載入跨配置的子資源時，系統會允許傳送或設定 SameSite=Strict 或 SameSite=Lax Cookie。現在，這類資源會與任何其他第三方或跨網站子資源一樣處理，也就是說，系統會封鎖任何 SameSite=Strict 或 SameSite=Lax Cookie。

此外，即使瀏覽器允許在安全網頁上載入不安全架構的資源，系統也會封鎖這些要求中的所有 Cookie，因為第三方或跨網站 Cookie 需要 Secure。

POSTing 表單

先前在網站的跨架構版本之間發布內容時，系統會傳送以 SameSite=Lax 或 SameSite=Strict 設定的 Cookie。現在這會視為跨網站 POST，只能傳送 SameSite=None Cookie。如果網站預設提供不安全的版本，但會在使用者提交登入或結帳表單時升級至安全版本，您可能會遇到這種情況。

與子資源相同，如果要求是從安全環境 (例如 HTTPS) 傳送至不安全環境 (例如 HTTP)，系統會封鎖這些要求中的所有 Cookie，因為第三方或跨網站 Cookie 需要 Secure。

如何測試我的網站？

Chrome 和 Firefox 均提供開發人員工具和訊息。

從 Chrome 86 開始，開發人員工具的「問題」分頁會納入 Schemeful Same-Site 問題。系統可能會為您的網站醒目顯示下列問題。

導航問題：

• 「完全遷移至 HTTPS，繼續在同網站要求中傳送 Cookie」：警告指出 Cookie 將在未來的 Chrome 版本中遭到封鎖。
• 「完全遷移至 HTTPS，以便在同網站要求中傳送 Cookie」：警告 Cookie 已遭封鎖。

子資源載入問題：

• 「完全遷移至 HTTPS，繼續將 Cookie 傳送至同網站子資源」或「完全遷移至 HTTPS，繼續允許同網站子資源設定 Cookie」：警告指出 Cookie 將在未來的 Chrome 版本中遭到封鎖。
• 「完全遷移至 HTTPS，將 Cookie 傳送至同網站子資源」或「完全遷移至 HTTPS，允許同網站子資源設定 Cookie」：Cookie 已遭封鎖的警告。POST 表單時，也可能會出現後者警告。

詳情請參閱「Testing and Debugging Tips for Schemeful Same-Site」。

從 Firefox 79 開始，如果透過 about:config 將 network.cookie.sameSite.schemeful 設為 true，控制台就會顯示 Schemeful Same-Site 問題的訊息。網站上可能會顯示下列內容：

• 「Cookie cookie_name 即將視為針對 http://site.example/ 的跨網站 Cookie，因為網址架構不符。」
• 「Cookie cookie_name 已視為與 http://site.example/ 相關的跨網站 Cookie，因為網址架構不相符。」

常見問題

我的網站已完全支援 HTTPS，為什麼瀏覽器的開發人員工具仍顯示問題？

您的部分連結和子資源可能仍指向不安全的網址。

如要修正這個問題，其中一種做法是使用 HTTP 嚴格傳輸安全性 (HSTS) 和 includeSubDomain 指令。有了 HSTS + includeSubDomain，即使網頁意外包含不安全的連結，瀏覽器也會自動改用安全版本。

如果無法升級為 HTTPS，該怎麼辦？

我們強烈建議您將網站全面升級為 HTTPS，以保護使用者安全。如果無法自行升級，建議您與主機服務供應商聯絡，瞭解他們是否提供這項服務。如果您是自行代管，Let's Encrypt 提供多種工具，可安裝及設定憑證。您也可以考慮將網站移至 CDN 或其他可提供 HTTPS 連線的 Proxy 後方。

如果還是無法存取，請嘗試放寬受影響 Cookie 的 SameSite保護措施。

• 如果系統只封鎖 SameSite=Strict Cookie，您可以將保護等級調降為 Lax。
• 如果系統同時封鎖 Strict 和 Lax Cookie，且 Cookie 傳送至 (或設定自) 安全網址，您可以將保護措施降級為 None。
  • 如果傳送 Cookie (或從中設定 Cookie) 的網址不安全，這個解決方法會失敗。這是因為 SameSite=None 需要 Cookie 上的 Secure 屬性，這表示這些 Cookie 可能無法透過不安全的連線傳送或設定。在這種情況下，網站升級為 HTTPS 前，您將無法存取該 Cookie。
  • 請注意，這只是暫時做法，因為第三方 Cookie 最終會全面淘汰。

如果我尚未指定 SameSite 屬性，這項異動對我的 Cookie 有何影響？

沒有 SameSite 屬性的 Cookie 會被視為指定 SameSite=Lax，且這些 Cookie 也適用相同的跨通訊協定行為。請注意，不安全方法的暫時例外狀況仍適用，詳情請參閱 Chromium SameSite 常見問題中的「Lax + POST 緩和措施」。

WebSocket 會受到哪些影響？

如果 WebSocket 連線與網頁的安全性相同，仍會視為同網站。

同網站：

• wss:// 個連線 (來自 https://)
• ws:// 個連線 (來自 http://)

跨網站：

• wss:// 個連線 (來自 http://)
• ws:// 個連線 (來自 https://)