「相同網站」的定義已經開始加入網址配置,因此 HTTP 和 HTTPS 版網站之間的連結現在會計算為跨網站要求。請預設升級至 HTTPS,這麼做可避免發生問題,或是繼續閱讀詳細資訊,進一步瞭解需要使用 SameSite 屬性值。
騙人 同網站 將 (網站) 網站的定義從可註冊的網域修改為 通訊協定 + 可註冊的網域。如需更多詳細資料和範例,請前往 瞭解「相同網站」和 "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。](https://web.dev/static/articles/schemeful-samesite/image/a-cross-scheme-navigation-209071cf80318.png?authuser=8&hl=zh-tw)
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。](https://web.dev/static/articles/schemeful-samesite/image/a-cross-scheme-subresourc-ee291fec730b8.png?authuser=8&hl=zh-tw)
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。](https://web.dev/static/articles/schemeful-samesite/image/a-cross-scheme-form-submi-528e4c1eb4c83.png?authuser=8&hl=zh-tw)
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 將
- 如果您是要傳送 Cookie 的網址 (或
設定) 並不安全。這是因為
如果我未指定 SameSite
屬性,這對我的 Cookie 有何影響?
系統會將不含 SameSite
屬性的 Cookie 視為指定
SameSite=Lax
和跨配置行為同樣適用於這些 Cookie,
請注意,不安全方法的暫時例外狀況仍然適用,請參閱
Chromium 中的 Lax + POST 緩解措施SameSite
常見問題。
WebSocket 會受到哪些影響?
WebSocket 連線若相同,則仍會視為相同網站 確保網頁的安全性
同網站:
- 來自
https://
的wss://
連線 - 來自
http://
的ws://
連線
跨網站:
- 來自
http://
的wss://
連線 - 來自
https://
的ws://
連線
相片來源:Julissa 卡德迪拉 為 禁用