本頁面由 Cloud Translation API 翻譯而成。

參照網址和參照網址政策最佳做法

Maud Nalpas

本頁概述設定「參照網址政策」和透過傳入要求中的參照網址。

摘要

非預期的跨來源資訊外洩問題會對網路使用者造成不良影響隱私權。A 罩杯防護參照網址政策可以派上用場。
建議設定 strict-origin-when-cross-origin 參照網址政策。這項服務保留參照網址大部分實用性，同時降低跨來源洩漏資料
請勿使用參照網址進行跨網站偽造要求 (CSRF) 防護。使用 CSRF 權杖和其他標頭增添多一層安全保障。

，瞭解如何調查及移除這項存取權。

Referer 和 Referrer-Policy 101

HTTP 要求可包含選用的 Referer 標頭、，指出發出請求的來源或網頁網址。 Referrer-Policy 標頭定義 Referer 標頭中可用的資料。

在以下範例中，Referer 標頭包含要求來源的 site-one 網頁。

包含 Referer 標頭的 HTTP 要求。 — 含有 Referer 標頭的 HTTP 要求。

Referer 標頭可能會出現在不同的要求類型中：

使用者點選連結時的「導覽」要求。
子資源要求 (如果瀏覽器要求圖片、iframe、指令碼和網頁所需的其他資源

在導覽和 iframe 中，您也可以使用 JavaScript 存取此資料： document.referrer。

您可以從 Referer 值中學習許多。例如數據分析服務判斷 site-two.example 上 50% 的訪客 social-network.example起。但包含完整網址時查詢字串都會透過 Referer 跨來源傳送，因此可能會危害使用者隱私權和產生安全性風險：

對應至不同隱私權和安全性風險的網址。 — 使用完整網址可能會影響使用者隱私和安全性。

網址 1 到 5 包含私人資訊，有時也會包含私人資訊或識別資訊。在不同來源間以無聲的方式揭露這些行為，可能有助於破壞網頁使用者隱私權。

網址 #6 是功能網址。如果是除了預期使用者會收到以外，惡意人士可以操控此帳戶。

如要限制網站所能接收的參照網址資料，可以設定參照網址政策

有哪些可用的政策？有哪些差異？

你可以從八項政策中選擇其中一項。視政策而定可用的 Referer 標頭 (和 document.referrer) 可以是：

沒有資料 (沒有 Referer 標頭)
僅限來源
完整網址：來源、路徑和查詢字串

，瞭解如何調查及移除這項存取權。

可能存在的資料
包含在 Referer 標頭和 document.referrer 中。 — 參照網址資料範例。

部分政策的設計會根據內容而有所不同：跨來源或相同來源要求，無論要求目的地是做為來源，或同時採用這兩種做法。適合用來限制跨來源共用或至較不安全的來源共用，同時仍保有豐富多樣性來源網址的格式。

下表列出參照網址政策如何限制可存取的網址資料從 Referer 標頭和 document.referrer 擷取：

政策範圍	政策名稱	參照網址：沒有資料	參照網址：僅限來源	參照網址：完整網址
未考量要求內容	`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 來源的要求與從 HTTPS 來源傳送至另一個 HTTP 來源的要求相同 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` 類似但有一些具體的差異詳情請見防止追蹤預防追蹤取得詳細資料。

設定參照網址政策的最佳做法

目標：明確設定隱私權加強政策，例如 strict-origin-when-cross-origin(或更嚴格的政策)。

你可以透過多種方式為網站設定參照網址政策：

做為 HTTP 標頭
在您的 HTML
按個別請求從 JavaScript

您可以針對不同的網頁、要求或元素設定不同政策。

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 已傳送。

Chrome 開發人員工具「網路」面板的螢幕截圖，顯示 Referer 和 Referrer-Policy。 — Chrome 開發人員工具已選取要求的「Network」面板。

我應該為網站設定哪一項政策？

強烈建議你明確設定隱私權加強政策，例如 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 收到的資料比以往少。
越來越多瀏覽器使用參照網址政策 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，以及而非 Referer，請使用以下標頭： Origin。 (適用於 POST 和 CORS 要求) Sec-Fetch-Site (如適用)。

記錄及偵錯

務必保護使用者可能儲存在 Google Cloud 產品/服務中的 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 商家網站沒有參照網址時，Referer 會發生什麼事政策會重新導向 HTTPS 付款服務供應商嗎？

HTTPS 付款服務供應商的要求中未顯示 Referer，因為大多數瀏覽器使用 strict-origin-when-cross-origin 或如果網站未設定政策，則預設為 no-referrer-when-downgrade。 Chrome 改用新的預設政策這個行為不會改變

結論

制定受保護的參照網址政策可有效保障使用者隱私權。

如要進一步瞭解各種保護使用者的技巧，請參閱安全無虞收集

資源

非常感謝所有評論者的貢獻和意見回饋，特別是 Kaustubha Govind David Van Cleve、Mike West、Sam Dutton、Rowan Merewood、Jxck 和 Kayce Basques。

參照網址和參照網址政策最佳做法

摘要

Referer 和 Referrer-Policy 101

有哪些可用的政策？有哪些差異？

瀏覽器的預設參照網址政策

設定參照網址政策的最佳做法

如何查看參照網址政策？

我應該為網站設定哪一項政策？

為什麼要「明確」？

為什麼選擇 strict-origin-when-cross-origin (或更嚴格的值)？

如果 strict-origin-when-cross-origin (或更嚴格的範圍) 不適用於您的所有用途，該怎麼辦？

範例：元素層級政策

例如：要求層級政策

您還應考慮哪些因素？

傳入要求的最佳做法

保護使用者資料

傳入參照網址可以變更 {referer-can-change}

Referer的替代方案

如果您只需要來源

如果您需要網址的其他元素 (路徑、查詢參數...)

如果無法使用以下替代方案：

跨網站偽造要求 (CSRF) 防護

記錄及偵錯

付款

付款流程安全性檢查的最佳做法

結論

資源

為什麼選擇 `strict-origin-when-cross-origin` (或更嚴格的值)？

如果 `strict-origin-when-cross-origin` (或更嚴格的範圍) 不適用於您的所有用途，該怎麼辦？

`Referer`的替代方案