「相同網站」的定義經過不斷演進,納入網址配置,因此網站的 HTTP 和 HTTPS 版本之間的連結現在會計為跨網站要求。請預設升級至 HTTPS,盡可能避免發生問題,或是繼續閱讀有關 SameSite 屬性值的詳細說明。
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 | 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 | 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 | 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 會全面淘汰。
- 如果您要傳送 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 網站