本頁面概略說明設定參照來源政策和在傳入要求中使用參照來源的最佳做法。
摘要
- 跨來源資訊的意外外洩會損害網頁使用者的隱私權。保護性參照網址政策可以提供協助。
- 建議您設定
strict-origin-when-cross-origin的參照來源政策。這麼做可保留大部分參照來源的用處，同時降低資料跨來源外洩的風險。 - 請勿使用參照來源來防範跨網站偽造要求 (CSRF)。請改用 CSRF 權杖，並使用其他標頭做為額外的安全防護層。
參照網址和參照網址政策入門
HTTP 要求可包含選用的 Referer 標頭，用於指出要求的來源或網頁網址。Referrer-Policy 標頭會定義 Referer 標頭中可用的資料。
在以下範例中，Referer 標頭包含發出要求的來源 site-one 上網頁的完整網址。
Referer 標頭可能會出現在不同類型的要求中：
- 使用者點選連結時的導覽要求。
- 瀏覽器要求，即瀏覽器要求的圖片、iframe、指令碼和其他資源。
針對導覽和 iframe，您也可以使用 document.referrer 透過 JavaScript 存取這項資料。
您可以從 Referer 值中學習許多。舉例來說，分析服務可能會使用這些資料判斷 site-two.example 的 50% 訪客來自 social-network.example。不過，如果在 Referer 跨來源中傳送包含路徑和查詢字串的完整網址，可能會危害使用者隱私，並造成安全性風險：
網址 1 到 5 包含私人資訊，有時還包含機密資訊或身分資訊。無論來源為何，都不發出通知，都可能危及網路使用者的隱私權。
網址 #6 是能力網址。如果並非預定的使用者收到此電子郵件，惡意人士就能控管該使用者的帳戶。
如要限制網站可接收哪些參照網址資料，您可以設定參照網址政策。
可用的政策有哪些？它們有何不同？
您可以選取八種政策中的一種。視政策而定，可透過 Referer 標頭 (和 document.referrer) 取得的資料如下：
- 沒有資料 (沒有
Referer標頭) - 僅限來源
- 完整網址：來源、路徑和查詢字串
部分政策的運作方式會因情境而異：跨來源或同源要求、要求目的地是否與來源一樣安全，或兩者皆是。這項功能可用於限制跨來源或傳送至安全性較低的來源的資訊量，同時維持網站內參照網址的豐富度。
下表說明參照網址政策如何限制參照網址標頭和 document.referrer 提供的網址資料：
| 政策範圍 | 政策名稱 | Referer：無資料 | 參照網址：僅限來源 | 參照網址：完整網址 |
|---|---|---|---|---|
| 不考量要求背景 | no-referrer |
勾號 | ||
origin |
檢查 | |||
unsafe-url |
勾號 | |||
| 以安全性為重 | strict-origin |
從 HTTPS 到 HTTP 的要求 | 從 HTTPS 到 HTTPS 或從 HTTP 到 HTTP 的請求 |
|
no-referrer-when-downgrade |
從 HTTPS 到 HTTP 的要求 | 從 HTTPS 到 HTTPS 或從 HTTP 到 HTTP 的請求 |
||
| 注重隱私權 | origin-when-cross-origin |
跨來源要求 | 相同來源要求 | |
same-origin |
跨來源要求 | 相同來源要求 | ||
| 以隱私權和安全性為重點 | strict-origin-when-cross-origin |
從 HTTPS 要求轉換為 HTTP | 跨來源要求： HTTPS 到 HTTPS 或 HTTP 到 HTTP |
相同來源要求 |
MDN 提供完整的政策和行為範例清單。
設定參照網址政策時，請注意下列事項：
- 所有考量到通訊協定 (HTTPS 與 HTTP) 的政策 (
strict-origin、no-referrer-when-downgrade和strict-origin-when-cross-origin) 會以相同方式處理從一個 HTTP 來源傳送至另一個 HTTP 來源的要求，以及從 HTTPS 來源傳送至另一個 HTTPS 來源的要求，即使 HTTP 的安全性較低。這是因為這些政策的關鍵在於是否發生安全性「降級」，也就是是否可將加密來源的資料公開給未加密的來源，如同 HTTPS → HTTP 要求。HTTP → HTTP 要求完全未加密，因此不會降級。 - 如果要求是同源，表示配置 (HTTPS 或 HTTP) 相同，因此不會降級安全性。
瀏覽器的預設參照網址政策
2021 年 10 月起
如果未設定參照網址政策，瀏覽器會使用預設政策。
| 瀏覽器 | 預設Referrer-Policy / 行為 |
|---|---|
| Chrome |
預設為 strict-origin-when-cross-origin。 |
| Firefox |
預設為 strict-origin-when-cross-origin。從93 版開始，對於嚴格追蹤防護和私密瀏覽使用者，系統會忽略跨網站要求的較寬鬆參照來源政策 no-referrer-when-downgrade、origin-when-cross-origin 和 unsafe-url，也就是說，無論網站的政策為何，系統一律會裁減跨網站要求的參照來源。 |
| Edge |
預設為 strict-origin-when-cross-origin。 |
| Safari |
預設值與 strict-origin-when-cross-origin 類似，但有幾項特定差異。詳情請參閱「
防止追蹤預防追蹤」一節。 |
設定參照來源政策的最佳做法
您可以透過下列幾種方式為網站設定參照網址政策：
您可以針對不同的網頁、要求或元素設定不同政策。
HTTP 標頭和中繼元素都是網頁層級。判斷元素有效政策的優先順序如下：
- 元素層級政策
- 網頁層級政策
- 瀏覽器預設值
範例：
index.html：
<meta name="referrer" content="strict-origin-when-cross-origin" />
<img src="..." referrerpolicy="no-referrer-when-downgrade" />
系統會使用 no-referrer-when-downgrade 政策要求圖片，而此頁面上的所有其他子資源要求都會遵循 strict-origin-when-cross-origin 政策。
如何查看參照來源政策？
securityheaders.com 可以用來判斷特定網站或網頁使用哪項政策。
您也可以使用 Chrome、Edge 或 Firefox 中的開發人員工具，查看特定要求使用的參照網站政策。在撰寫本文時，Safari 不會顯示 Referrer-Policy 標頭，但會顯示已傳送的 Referer。
您應為網站設定哪項政策？
強烈建議您明確設定隱私權強化政策，例如 strict-origin-when-cross-origin (或更嚴格)。
為什麼要「明確」？
如果您沒有設定參照網址政策，系統會使用瀏覽器的預設政策。事實上，網站通常會採用瀏覽器的預設值。但這並非理想做法，因為：
- 不同的瀏覽器有不同的預設政策，因此如果您依賴瀏覽器預設值，您的網站在不同瀏覽器上的行為就無法預測。
- 瀏覽器採用更嚴格的預設值，例如
strict-origin-when-cross-origin，以及參照網址裁剪等機制，用於跨來源要求。在瀏覽器預設值變更前明確選擇採用隱私權加強政策，即可控管自己的設定，並協助您視需要執行測試。
為什麼是 strict-origin-when-cross-origin (或更嚴格)？
您需要制定安全、有助於提升隱私權，且實用的政策。「實用」的定義取決於您希望參照來源提供哪些資訊：
- 安全性：如果您的網站使用 HTTPS (如果沒有，請優先採用)，您不希望網站的網址在非 HTTPS 要求中外洩。由於任何網路使用者都能看到這些資訊，因此資料外洩會讓使用者暴露在中間的攻擊中。
no-referrer-when-downgrade、strict-origin-when-cross-origin、no-referrer和strict-origin政策可解決這個問題。 - 強化隱私權：針對跨來源要求，
no-referrer-when-downgrade會分享完整網址，這可能會造成隱私權問題。strict-origin-when-cross-origin和strict-origin只會共用來源，而no-referrer則不會分享任何內容。這會讓您使用strict-origin-when-cross-origin、strict-origin和no-referrer做為隱私權強化選項。 - 實用性：
no-referrer和strict-origin絕不會分享完整網址，即使是同源請求也不例外。如果您需要完整的網址，建議使用strict-origin-when-cross-origin。
這意味著，strict-origin-when-cross-origin 通常是明智的選擇。
範例：設定 strict-origin-when-cross-origin 政策
index.html：
<meta name="referrer" content="strict-origin-when-cross-origin" />
或伺服器端，例如在 Express 中：
const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));
如果 strict-origin-when-cross-origin (或更嚴格) 不適用於您的所有用途，該怎麼辦？
在這種情況下，請採取漸進式做法：為網站設定 strict-origin-when-cross-origin 等防護政策，並視需要為特定要求或 HTML 元素設定較寬鬆的政策。
範例：元素層級政策
index.html：
<head>
<!-- document-level policy: strict-origin-when-cross-origin -->
<meta name="referrer" content="strict-origin-when-cross-origin" />
<head>
<body>
<!-- policy on this <a> element: no-referrer-when-downgrade -->
<a src="…" href="…" referrerpolicy="no-referrer-when-downgrade"></a>
<body></body>
</body>
</head>
</head>
Safari/WebKit 可能會為跨網站要求設定 document.referrer 或 Referer 標頭上限。請參閱詳細說明。
例如：要求層級政策
script.js：
fetch(url, {referrerPolicy: 'no-referrer-when-downgrade'});
您還應考慮哪些事項？
政策應視您的網站和用途而定，由您、您的團隊和公司決定。如果部分網址含有身分或機密資料，請設定保護政策。
傳入要求的最佳做法
如果您的網站使用了傳入要求的參照網址，請參考以下指南。
保護使用者資料
Referer 可能包含私人、個人或身分識別資料，因此請務必妥善處理。
來自外部網站的參照網址可以變更 {referer-can-change}
使用來自跨來源要求的參照網址時，有幾項限制：
- 如果您無法控制要求供應器的實作方式，就無法假設收到的
Referer標頭 (和document.referrer) 有所假設。要求輸出器可能會隨時決定改用no-referrer政策，或改用比之前更嚴格的政策。也就是說，您從Referer收到的資料會比先前少。 - 越來越多瀏覽器會預設使用 Referrer-Policy
strict-origin-when-cross-origin。也就是說，如果來源網站未設定政策，您現在可能會在收到的跨來源要求中，只收到來源，而非完整的參照網址。 - 瀏覽器可能會變更管理
Referer的方式。舉例來說，部分瀏覽器開發人員可能會決定一律在跨來源子資源要求中裁剪來源參照，以保護使用者隱私。 Referer標頭 (和document.referrer) 包含的資料可能超出所需數量。舉例來說，如果您只想知道要求是否跨來源，就可能會使用完整網址。
Referer的替代方案
如果符合下列情況，您可能需要考慮其他選項：
- 網站的一項重要功能會使用傳入跨來源要求的參照網址。
- 您的網站無法再透過跨來源要求接收參照網址部分。當要求發出政策變更，或是未設定政策且瀏覽器預設值變更時 (例如在 Chrome 85 中) 變更時，就會發生這種情況。
如要定義替代網址，請先分析您使用的參照網址部分。
如果您只需要來源
- 如果您在具有網頁頂層存取權的指令碼中使用參照來源，
window.location.origin是另一個替代做法。 - 在適用情況下，
Origin和Sec-Fetch-Site等標頭會提供Origin或說明要求是否為跨來源，這可能是您需要的項目。
如果需要網址的其他元素 (路徑、查詢參數...)
- 要求參數可能可解決您的用途，省去解析參照網址的工作。
- 如果您在具有網頁頂層存取權的指令碼中使用參照來源，
window.location.pathname可能會是替代方案。請只擷取網址的路徑區段，並將其做為引數傳遞，因此系統不會傳遞網址參數中的任何潛在機密資訊。
如果無法使用以下替代方案：
- 請確認您是否可以變更系統，以便要求發送端 (例如
site-one.example) 在某種設定中明確設定所需資訊。- 優點：對
site-one.example使用者提供更明確、更能保護隱私權，更能因應未來的需求。 - 缺點：可能在操作端或系統使用者執行更多工作。
- 優點：對
- 確認發出要求的網站是否同意設定每個元素或每個要求的 Referrer-Policy 為
no-referrer-when-downgrade。- 缺點：可能無法為
site-one.example使用者提供較佳的隱私權保護，且可能無法在所有瀏覽器中支援。
- 缺點：可能無法為
跨網站偽造要求 (CSRF) 防護
請求發送端可以隨時設定 no-referrer 政策，決定是否傳送參照來源，而惡意人士甚至可以偽造參照來源。
使用 CSRF 符記做為主要防護機制。為提供額外保護，請使用 SameSite，並改用 Origin 等標頭 (適用於 POST 和 CORS 要求)，以及 Sec-Fetch-Site (如有)，而非 Referer。
記錄及偵錯
請務必保護可能存在於 Referer 中的使用者個人或私密資料。
如果您只使用來源，請檢查是否可以改用 Origin 標頭。這或許可讓您以更簡單的方式取得偵錯時所需的資訊，而不必剖析參照網址。
付款
付款服務供應商可能會依賴傳入要求的 Referer 標頭進行安全性檢查。
例如：
- 使用者在
online-shop.example/cart/checkout按一下「購買」按鈕。 online-shop.example會重新導向至payment-provider.example，以便管理交易。payment-provider.example會根據商家設定的允許Referer值清單，檢查此要求的Referer。如果不符合清單中的任何項目，payment-provider.example就會拒絕要求。如果相符，使用者就能繼續交易。
付款流程安全性檢查的最佳做法
付款服務供應商可以使用 Referer 做為基本檢查，以防範某些攻擊。不過，Referer 標頭本身並非檢查的可靠依據。無論是否為合法商家，要求網站都能設定 no-referrer 政策，讓付款供應商無法取得 Referer 資訊。
檢視 Referer 可能有助於付款服務供應商找出未設定 no-referrer 政策的初學者攻擊者。如果您使用 Referer 做為第一個檢查步驟：
- 請勿預期
Referer一律會存在。如果有，請只根據可納入的資料最小值 (也就是來源) 進行檢查。- 設定允許的
Referer值清單時，請務必只納入來源，不要納入路徑。 - 舉例來說，
online-shop.example允許的Referer值應為online-shop.example，而不是online-shop.example/cart/checkout。如果預期完全沒有Referer或僅為要求網站來源的Referer值，就能防止因商家Referrer-Policy假設而發生錯誤的錯誤。
- 設定允許的
- 如果
Referer不存在，或是存在但基本Referer來源檢查成功，您可以改用其他更可靠的驗證方法。
為確保付款驗證作業更可靠，請要求發送端對要求參數進行雜湊運算，並搭配使用專屬索引鍵。付款服務供應商接著在您這邊計算相同的雜湊值，並只在該值與您計算的值相符時接受要求。
當沒有參照來源政策的 HTTP 商家網站重新導向至 HTTPS 付款供應商時，Referer會發生什麼情況？
向 HTTPS 付款供應商提出要求時，系統不會顯示 Referer，因為大多數瀏覽器預設會在網站沒有政策設定時使用 strict-origin-when-cross-origin 或 no-referrer-when-downgrade。Chrome 改用新的預設政策不會影響這項行為。
結論
保護性參照來源政策是讓使用者享有更多隱私權的絕佳方式。
如要進一步瞭解保護使用者的各種技巧，請參閱安全無虞系列
資源
- 瞭解「同網站」和「同來源」
- 新的安全性頁首：參照來源政策 (2017 年)
- MDN 的參照網址政策
- 參照網站標頭：MDN 的隱私權和安全性問題
- Chrome 異動：要導入的閃爍意圖
- Chrome 異動：Blink 意圖將發布
- Chrome 變更：狀態項目
- Chrome 異動：85 版 Beta 版的部落格文章
- Referrer 修剪 GitHub 主題：不同瀏覽器的做法
- Referrer-Policy 規格
感謝所有審查員提供意見和回饋，特別是 Kaustubha Govind、David Van Cleve、Mike West、Sam Dutton、Rowan Merewood、Jxck 和 Kayce Basques。