配置的同網站

「相同網站」的定義已經開始加入網址配置，因此 HTTP 和 HTTPS 版網站之間的連結現在會計算為跨網站要求。請預設升級至 HTTPS，這麼做可避免發生問題，或是繼續閱讀詳細資訊，進一步瞭解需要使用 SameSite 屬性值。

Steven Bingler
Steven Bingler
GitHub
Rowan Merewood

騙人 同網站 將 (網站) 網站的定義從可註冊的網域修改為 通訊協定 + 可註冊的網域。如需更多詳細資料和範例，請前往 瞭解「相同網站」和 "same-origin"。

好消息是，如果你的網站已全面升級為 HTTPS 你不必擔心什麼事情您不會有任何改變。

如果您尚未將網站全面升級，這應該是優先升級的選擇。 不過，有時候您的網站訪客會切換使用 HTTP 和 接著是 HTTPS 的部分常見情境和相關 SameSite Cookie 將概略顯示。

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

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

導致 SameSite=Lax 變為預設值的其中一個主要原因之一 Cookie 是為了防止跨網站偽造要求 (CSRF)。不過 不安全的 HTTP 流量仍為網路攻擊者提供 竄改 Cookie 之後將用於安全 HTTPS 版本的 網站。在配置之間建立額外的跨網站界線， 進一步防範這些攻擊

常見交叉配置情境

在網站的跨配置版本之間切換 (例如從 http://site.example 變更為 https://site.example) 先前允許 要傳送的 SameSite=Strict 個 Cookie。系統會將其視為跨網站 這代表系統將封鎖 SameSite=Strict 個 Cookie。

經由網站不安全 HTTP 版本上的連結前往安全 HTTPS 版本時，即觸發跨配置瀏覽。SameSite=Strict Cookie 遭到封鎖、SameSite=Lax 和 SameSite=None;已允許安全 Cookie。
從 HTTP 到 HTTPS 的跨配置瀏覽。
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ 已封鎖 ⛔ 已封鎖
SameSite=Lax ✓ 允許 ✓ 允許
SameSite=None;Secure ✓ 允許 ⛔ 已封鎖

正在載入子資源

您在此處所做的任何變更，都應該視為暫時修正項目 升級作業

子資源包括圖片、iframe，以及透過 XHR 或 Fetch。

在網頁上載入跨配置子資源之前， 要傳送或設定 SameSite=Strict 或 SameSite=Lax Cookie。現在這已是 做法與處理其他第三方或跨網站子資源的方式相同 這表示任何 SameSite=Strict 或 SameSite=Lax Cookie 都會遭到封鎖。

此外，即使瀏覽器允許來自不安全的配置的資源， 在安全網頁上載入時，系統將封鎖這些請求的所有 Cookie，因為 第三方或跨網站 Cookie 需要 Secure。

資源所產生的跨配置子資源，源自於不安全 HTTP 版本的網站安全 HTTPS 版本所提供的資源。SameSite=Strict 和 SameSite=Lax Cookie 遭封鎖，以及 SameSite=None;已允許安全 Cookie。
HTTP 網頁，包含透過 HTTPS 執行跨配置子資源的 HTTP 網頁。
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ 已封鎖 ⛔ 已封鎖
SameSite=Lax ⛔ 已封鎖 ⛔ 已封鎖
SameSite=None;Secure ✓ 允許 ⛔ 已封鎖

張貼表單

在跨配置版本的網站之間發布內容，就是 需要透過 SameSite=Lax 或 SameSite=Strict 設定要傳送的 Cookie。現在這已是 系統會將其視為跨網站 POST，只能傳送 SameSite=None 個 Cookie。您可以 就會發生這個情況。 但必須在提交登入資料時為使用者升級至安全版本， 結帳表單。

與子資源一樣，如果要求是來自安全，例如轉換為 不安全，例如HTTP，因此在內容處理要求時，所有 Cookie 都會遭到封鎖 因為第三方或跨網站 Cookie 需要 Secure。

透過不安全 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 要求」：警告 Cookie「日後將遭到封鎖」 。
  • 「完全遷移至 HTTPS，讓 Cookie 透過相同網站要求傳送」—A 警告，表示 Cookie「已封鎖」。

子資源載入問題：

  • 「完全改用 HTTPS，以便繼續將 Cookie 傳送至同一個網站 子資源」或「完全改用 HTTPS，以便繼續允許 Cookie ： 是由相同的網站子資源設定」—警告，但請注意，Cookie「會」 封鎖功能。
  • 「完全遷移至 HTTPS，讓 Cookie 傳送至同網站子資源」 或是「完全改用 HTTPS，以便讓相同網站設定 Cookie 子資源」：警告 Cookie「已遭封鎖」。後者 警示訊息

詳情請參閱 Scheemful 的測試與偵錯提示 Same-Site。

來自 Firefox 79，其中 network.cookie.sameSite.schemeful 設為透過以下瀏覽器：true about:config，控制台會顯示與 Schemeful Same-Site 問題相關的訊息。 您可能會在網站上看到以下內容：

  • "Cookie cookie_name 即將視為跨網站 Cookie 無法 http://site.example/。」
  • 「Cookie cookie_name 已被」視為跨網站 http://site.example/。」

常見問題

我的網站已經完全透過 HTTPS 提供，為什麼瀏覽器的 DevTools 會出現問題？

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

解決方法之一是使用 HTTP 嚴格傳輸安全性 (HSTS) 和 includeSubDomain 指令。含嚴格傳輸安全性 (HSTS) + includeSubDomain 偶數 您的某個網頁意外加入了不安全的連結 會自動改用安全版本。

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

雖然強烈建議你將網站完全升級至 HTTPS， 如果無法自行提示，建議您洽詢 查看對方是否提供該選項如果您是自行主辦人 Let's Encrypt 提供多種工具， 安裝及設定憑證您亦可調查移動網站的問題 也就是能提供 HTTPS 連線的 Proxy 或其他 Proxy

如果還是無法解決問題，請嘗試放寬 SameSite 保護功能 受影響的 Cookie。

  • 如果只封鎖 SameSite=Strict 個 Cookie，你可以調降 保護 Lax
  • 在 Strict 和 Lax 都遭到封鎖，且你的 系統正在傳送 (或設定) 安全網址，您可以降低 保護 None
    • 如果您是要傳送 Cookie 的網址 (或 設定) 並不安全。這是因為 SameSite=None 需要 Secure 屬性，也就是說，系統可能不會傳送 Cookie 或 透過不安全的連線設定在這種情況下，您將無法存取 直到網站升級為 HTTPS 為止
    • 請注意，這是暫時性的，因為最終的第三方 Cookie 將

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

系統會將不含 SameSite 屬性的 Cookie 視為指定 SameSite=Lax 和跨配置行為同樣適用於這些 Cookie， 請注意，不安全方法的暫時例外狀況仍然適用，請參閱 Chromium 中的 Lax + POST 緩解措施SameSite 常見問題。

WebSocket 會受到哪些影響？

WebSocket 連線若相同，則仍會視為相同網站 確保網頁的安全性

同網站：

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

跨網站：

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

相片來源：Julissa 卡德迪拉 為 禁用