本頁面將概略說明設定 Referrer-Policy，以及在傳入要求中使用參照網址的最佳做法。
摘要
- 非預期的跨來源資訊外洩會損害網路使用者的隱私權。這時不妨採用防護型參照政策。
- 建議您設定
strict-origin-when-cross-origin的參照政策。這項功能可保留大部分的參照網址實用性，同時降低跨來源資料外洩的風險。 - 請勿使用參照網址來防範跨網站偽造要求 (CSRF) 攻擊。請改用 CSRF 權杖，並使用其他標頭做為額外的安全防護層。
參照網址和參照網址政策 101
HTTP 要求可以包含選用的 Referer 標頭，指出要求來源或要求發出的網頁網址。「Referrer-Policy」標頭會定義 Referer 標頭中提供的資料。
在下列範例中，Referer 標頭包含要求來源網頁的完整網址 (位於 site-one)。
Referer 標頭可能會出現在不同類型的要求中：
- 使用者點按連結時的導覽要求。
- 子資源要求：瀏覽器要求圖片、iframe、指令碼和網頁所需的其他資源。
如果是導覽和 iframe，您也可以使用 JavaScript 透過 document.referrer 存取這項資料。
您可以從 Referer 值中學到很多。舉例來說，數據分析服務可能會使用這些 Cookie，判斷 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，因此無論網站政策為何，系統一律會針對跨網站要求截斷參照網址。
|
| 邊緣 |
預設值為 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使用者隱私權、更符合未來趨勢。 - 缺點：您或系統使用者可能需要付出更多心力。
- 優點：更明確、更注重
- 檢查發出要求的網站是否同意設定每個元素或每個要求的參照網址政策
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且基本Referer來源檢查成功，您可以改用其他更可靠的驗證方法。
為確保付款驗證的可靠性，請讓要求者將要求參數與專屬金鑰一起雜湊處理。付款服務供應商隨後會在您這邊計算相同的雜湊值，並只在與您的計算結果相符時接受要求。
如果沒有參照網址政策的 HTTP 商家網站重新導向至 HTTPS 付款服務供應商，Referer 會發生什麼情況？
在傳送給 HTTPS 付款服務供應商的要求中，不會顯示 Referer，因為網站未設定任何政策時，大多數瀏覽器預設會使用 strict-origin-when-cross-origin 或 no-referrer-when-downgrade。Chrome 變更為新的預設政策不會改變這種行為。
結論
採用保護性參照網址政策，可為使用者提供更完善的隱私權保障。
如要進一步瞭解保護使用者的不同技術，請參閱「安全無虞」系列文章。
資源
- 瞭解「同網站」和「同源」
- 新的安全性標頭：Referrer Policy (2017 年)
- MDN 上的 Referrer-Policy
- Referer 標頭：MDN 上的隱私權和安全性疑慮
- Chrome 變更：實作 Blink 意圖
- Chrome 變更：Blink 意圖出貨
- Chrome 變更：狀態項目
- Chrome 變更：85 Beta 版 網誌文章
- 參照 GitHub 討論串中的參照網址修剪：不同瀏覽器的做法
- 參照網址政策規格
特別感謝 Kaustubha Govind、David Van Cleve、Mike West、Sam Dutton、Rowan Merewood、Jxck 和 Kayce Basques 等審查人員的貢獻和意見回饋。