本頁面概略說明設定參照網址政策，以及在傳入要求中使用參照網址的最佳做法。
摘要
- 非預期的跨來源資訊外洩會損害網路使用者的隱私權。保護參照網址政策可以提供協助。
- 建議您將參照政策設為
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標頭) - 僅限 origin
- 完整網址：來源、路徑和查詢字串
有些政策的設計會根據內容而以不同方式表現：跨來源要求或相同來源要求、要求目的地與來源是否安全，或同時採用兩者。這種做法適合用來限制跨來源或低安全性應用程式共用的資訊量，同時保有自家網站內參照網址的豐富功能。
下表顯示參照網址政策如何限制來自參照網址標頭和 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 來源傳送至另一個 HTTP 來源的要求，處理方式會與從 HTTPS 來源傳送至另一個 HTTPS 來源的要求相同，即使 HTTP 的安全性較低。這是因為在這些政策中，重要的是是否發生安全性「降級」；也就是如果要求可將加密來源的資料提供給未加密的來源，就像在 HTTPS → HTTP 要求中一樣。HTTP → HTTP 要求完全未加密，因此不會進行降級。 - 如果要求是 same-origin，表示配置 (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收到的資料會比以前少。 - 越來越多瀏覽器預設使用參照網址政策
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)，明確設定某種設定所需的資訊。- Pro：為
site-one.example使用者提供更為明確、更能保障隱私權，同時保障未來業務發展。 - 缺點：可能對您或系統使用者的工作機會更多。
- Pro：為
- 確認發出要求的網站是否同意為
no-referrer-when-downgrade設定個別元素或個別要求的參照網址政策。- 缺點：對於
site-one.example使用者的隱私權保護可能較低，部分瀏覽器可能不支援。
- 缺點：對於
跨網站偽造要求 (CSRF) 防護
要求發送器可以隨時設定 no-referrer 政策，決定不要傳送參照網址，這樣不肖人士甚至可能會冒用參照網址。
使用 CSRF 權杖做為主要防護。如需額外的安全防護，請使用 SameSite 而非 Referer，請使用 Origin (POST 和 CORS 要求可用) 和 Sec-Fetch-Site (如有) 等標頭。
記錄並偵錯
請務必保護可能位於 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 變更：Blink 意圖要實作
- Chrome 變更：Blink 意圖
- Chrome 變更：狀態項目
- Chrome 變更：85 Beta 版網誌文章
- Referrer 剪輯 GitHub 執行緒：不同瀏覽器的作用
- 參照網址政策規格
感謝所有評論者的貢獻和意見回饋，特別是 Kaustubha Govind、David Van Cleve、Mike West、Sam Dutton、Rowan Merewood、Jxck 和 Kayce Basques。