配置的同網站

「相同網站」的定義經過不斷演進，納入網址配置，因此網站的 HTTP 和 HTTPS 版本之間的連結現在會計為跨網站要求。請預設升級至 HTTPS，盡可能避免發生問題，或是繼續閱讀有關 SameSite 屬性值的詳細說明。

史蒂芬·賓格勒
Steven Bingler
GitHub
羅溫梅爾伍德

Schemeful Same-Site：將 (網站) 網站的定義從可註冊的網域修改為配置 + 可註冊的網域。如需更多詳細資訊和範例，請參閱瞭解「相同網站」和「相同來源」。

好消息是，如果您的網站已完全升級為 HTTPS，您就不必採取任何行動。不會受到任何影響。

若您尚未全面升級網站，請優先採取這種做法。 不過，如果網站訪客會在 HTTP 和 HTTPS 之間瀏覽，部分常見情境與相關的 SameSite Cookie 行為將概述如下。

無論是在 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，而這些 Cookie 之後將用於網站的安全 HTTPS 版本。在配置之間建立此額外的跨網站界線，可讓您進一步抵禦這些攻擊。

常見的跨配置情境

在網站的跨架構版本之間進行瀏覽 (例如從 http://site.example 連結到 https://site.example) 之後，系統會允許傳送 SameSite=Strict Cookie。系統現在將其視為跨網站瀏覽，也就是說系統將封鎖 SameSite=Strict Cookie。

網站含有不安全的 HTTP 版本連結，連至安全 HTTPS 版本，會觸發跨配置瀏覽。SameSite=嚴格 Cookie 封鎖、SameSite=Lax 和 SameSite=None; 安全 Cookie。
從 HTTP 到 HTTPS 的跨配置導覽。
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ 遭封鎖 ⛔ 遭封鎖
SameSite=Lax ✓ 允許 ✓ 允許
SameSite=None;Secure ✓ 允許 ⛔ 遭封鎖

正在載入子資源

您在此處進行的任何變更都應該只是暫時的修正，直到您設法升級至完整 HTTPS 為止。

子資源的範例包括透過 XHR 或 Fetch 產生的圖片、iframe 和網路要求。

在網頁上載入跨配置子資源後，就會允許傳送或設定 SameSite=Strict 或 SameSite=Lax Cookie。現在做法與任何其他第三方或跨網站子資源相同，也就是說，系統會封鎖任何 SameSite=Strict 或 SameSite=Lax Cookie。

此外，即使瀏覽器允許在安全網頁上載入不安全的資源，由於第三方或跨網站 Cookie 需要使用 Secure，因此這些要求中的所有 Cookie 都會遭到封鎖。

從不安全的 HTTP 版本網站中，源自安全 HTTPS 版本的資源所產生的跨配置子資源。SameSite=Strict 和 SameSite=Lax Cookie 遭到封鎖，且 SameSite=None; 安全的 Cookie。
HTTP 網頁，包括透過 HTTPS 的跨配置子資源。
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ 遭封鎖 ⛔ 遭封鎖
SameSite=Lax ⛔ 遭封鎖 ⛔ 遭封鎖
SameSite=None;Secure ✓ 允許 ⛔ 遭封鎖

張貼表單

在網站跨配置版本之間發布的內容，先前會允許傳送具有 SameSite=Lax 或 SameSite=Strict 的 Cookie。系統會將這項操作視為跨網站 POST，但只能傳送 SameSite=None 個 Cookie。因此，如果網站預設顯示不安全的版本，您可能會遇到這種情況，但在提交登入或結帳表單時，也可能將使用者升級至安全版本。

與子資源一樣，如果要求是從安全 (例如 HTTPS) 傳送至不安全的 (例如 HTTP)，則由於第三方或跨網站 Cookie 需要 Secure，因此這些要求中的所有 Cookie 都會遭到封鎖。

透過不安全的 HTTP 版本網站提交表單，並提交至安全 HTTPS 版本。SameSite=Strict 和 SameSite=Lax Cookie 遭到封鎖，且 SameSite=None; 安全的 Cookie。
從 HTTP 提交至 HTTPS 的跨配置表單。
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ 遭封鎖 ⛔ 遭封鎖
SameSite=Lax ⛔ 遭封鎖 ⛔ 遭封鎖
SameSite=None;Secure ✓ 允許 ⛔ 遭封鎖

如何測試網站？

你可以透過 Chrome 和 Firefox 使用開發人員工具和訊息功能。

自 Chrome 86 版起，開發人員工具中的「問題」分頁會包含 Schemeful Same-Site 問題。網站的下列問題可能會醒目顯示。

導覽問題：

  • 「遷移至 HTTPS 以繼續在相同網站要求中傳送 Cookie」：這項警告，系統日後的 Chrome 版本將封鎖 Cookie。
  • 「完全遷移至 HTTPS，以便在相同網站要求中傳送 Cookie」：警告，這個 Cookie 已經遭到封鎖。

子資源載入問題：

  • 「遷移至 HTTPS 以繼續將 Cookie 傳送至相同網站子資源」或「遷移至 HTTPS 以繼續允許相同網站子資源設定 Cookie」：警告，日後的 Chrome 版本將封鎖 Cookie。
  • 「遷移至 HTTPS 以將 Cookie 傳送至相同網站子資源」或「完全遷移至 HTTPS，讓相同網站子資源設定 Cookie」的警告訊息，指出 Cookie 已遭封鎖。發布表單時，系統也可能會顯示後者的警告。

詳情請參閱「配置相同網站的測試和偵錯提示」。

在 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/ 的跨網站處理」。

常見問題

我的網站已完全採用 HTTPS，為什麼會在瀏覽器的開發人員工具中發生問題？

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

其中一個解決方法是使用 HTTP Strict-Transport-Security (HSTS) 和 includeSubDomain 指令。即使其中一個網頁意外加入不安全的連結，使用 HSTS + includeSubDomain 之後，瀏覽器就會自動改用安全版本。

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

雖然我們強烈建議您將網站完全升級為 HTTPS 以保護使用者，但如果無法這麼做，建議您與主機供應商聯絡，瞭解對方是否提供這個選項。如果您是自行託管，則 Let's Encrypt 提供了許多可用來安裝和設定憑證的工具。您也可調查在提供 HTTPS 連線的 CDN 或其他 Proxy 背後移動網站。

如果還是無法解決問題，請嘗試針對受影響的 Cookie 放寬 SameSite 防護機制。

  • 如果只封鎖 SameSite=Strict Cookie，您可以降低 Lax 的防護能力。
  • 如果 Strict 和 Lax Cookie 都遭到封鎖，且您的 Cookie 會傳送至 (或設定) 安全網址，您可以降低保護程度為 None。
    • 如果您要傳送 Cookie 的目標網址 (或設定來源) 並不安全，這個解決方法就會失敗。這是因為 SameSite=None 需要 Cookie 上的 Secure 屬性，這代表 Cookie 可能無法透過不安全的連線傳送或設定。如果是這種情況，您必須先將網站升級至 HTTPS，才能存取該 Cookie。
    • 請注意，這只是暫時的，因為最終第三方 Cookie 會全面淘汰。

如果我沒有指定 SameSite 屬性，這對我的 Cookie 有何影響？

系統會將沒有 SameSite 屬性的 Cookie 視為指定 SameSite=Lax，並對這些 Cookie 採用相同的跨配置行為。請注意，不安全方法的暫時性例外狀況仍然適用，詳情請參閱 Chromium SameSite 常見問題中的 Lax + POST 因應措施。

WebSocket 會受到什麼影響？

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

同網站：

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

跨網站：

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

相片來源：Julissa Capdevilla 前往 Unsplash 網站